-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
[MT12] Default channel order, naming and default trims for these #4456
Comments
I'll just comment on that last point... trims inherit the name of the axis they are paired with... so if you call the TH axis A, the trim for it will be named A. I generally agree with the second point, in that we probably don't need that setting at all... especially when for the odd model you probably need to set up a completely custom mix order anyway. Although that does go against the principle of giving the user options... |
Isn't default channel order fixed already? And I fail to see the purpose of removing the setting, if you don't want to use it, then simply don't. If you for example only use those wltoys, then you will want to change default |
I'm wondering if we should have a settings for trims display, that would default to only the first two for surface radio |
The default for many WLToys is throttle on CH2 and steering on CH4. Which means it needs to be changed later anyway. In my opinion this default setting makes sense, if there are multiple commonly known values that people often use. |
I've renamed the source in the hardware page and the input in the input page, but the names of the trims didn't change, at least not in the input settings where I select them. Or did you mean that it's convention to name them this way? Or something completely different? Maybe it should also be considered, that the trim buttons on this surface radio are not placed nor labeled in a way that makes them obviously belong to a certain axis or control (like below or besides a certain stick). The device itself only labels them as T1 to T5. I therefore would tend to name them the same in the software to avoid confusion. At least if the whole naming thing is fixed as it appears to me at the moment. |
Has there been a decision on renaming the trims in the firmware to match the physical labels on the switches? It seems to be a source of confusion fairly regularly in the support groups. |
The trim name matches the axis they trim for the first 2 (so TH or ST), then trim number, as any other EdgeTX radio |
Yeah, but the correct order is ST and TH. The default order settings doesn't change that. If you look at the radio from the right side, you see that they are labeled "T1", "T2" and so on. One would expect that the first one defaults also for the first channel. I always mix up the trim switches with this radio because of that. BTW. the same is true for the Drive Mode setting, where the trims can be disabled or set to different mode values, the first one should be T1, the second T2 and so on, but they aren't. EDIT: As I wrote above the trim names do NOT change with the axis name, at least not for me. Also this wouldn't help if they are assigend to the "wrong" axis. |
Those are close to invisible on my MT12, but fixed those in #4582 Could you test on new blank SDcard ? ST should be on CH1, trimmed by T1 My understanding is it in this PR how it should be |
I agree, it now works as expected. I used a freshly formatted SD card only with the latest nightly (EdgeTX) stock contents and sound files. Debug keys output is now working as expected and the trim order in the Drive Mode page is now in the correct order, too. Thank you for your work BTW! :) |
I've been setting up my new radio and stumbled across this ticket. Is this in the 2.10 release candidate? |
yes |
Is there an existing issue for this feature request?
Is your feature request related to a problem?
I understand that the default channel order for this surface radio was initially TH-ST, although it can be changed to ST-TH in the sys menu, the default setting seems to be ST-TH now, which is good!
I still would recommend some considerations and/or optimizations for this, though.
Describe the solution you'd like
At the moment the user can switch between order options named "ST" and "TS", which is a bit inconvenient, since steering is also known as "ST". I would recommend using something as "ST, TH" and "TH, ST" for this option (two letters instead of one, since that's what surface users are accustomed to, while in the air "domain", user are used to only one letter naming (A,E,T,R), in the surface "domain" they use two letters (ST, TH) for ages.
The next question would be, if this option is necessary at all, since I've never came across a radio or receiver that uses another than channel order than ST-TH (CH1: Steering CH2: Throttle). Or in other well known words: "One to turn, two to burn."
There are some very rare exceptions (for examples some WLToys models), but the user can always change the channel order anyway. As I understand, this is just a convenience thing for newly created models.
Personally, I would simply get rid of it and set the default channel order for newly generated surface models always to "ST-TH". This is an air "thing", because there are these different modes and channel orders for air, but for surface it's much simpler -- and why make it more complicated again? The number of people who will want to set this per default to TH-ST is virtually zero.
The trim "T1" is named "TH" and the "T2" is named "ST", which, I assume goes back to the initially different channel order. Maybe they should be rename to T1: "ST" and T2: "TH" (it's not labeled on the device itself, device uses "T1" to "T5". Or name it to "T1" and "T2". But the current names are misleading, especially when the correct channel order is selected.
Personally, I would name them "T1" and "T2" but still use T1 for steering trim and T2 for throttle trim per default. This is consistent with the device labeling and makes sense on a logical level, too.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: