-
-
Notifications
You must be signed in to change notification settings - Fork 333
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
Input Source - discrepancy between color and B&W radios #4998
Comments
philmoz
added
bug 🪲
Something isn't working
triage
Bug report awaiting review / sorting
labels
May 13, 2024
Blame history suggests it was changed in 2.5 as part of a bug fix. This is
pre LVGL...
#739
Although `isSourceAvailableInInputs` exists, in the first instance I
personally would prefer much of the current behaviour to stay, so would be
more in favor of ditching it entirely in favor of isSourceAvailable.
…On Mon, May 13, 2024 at 7:16 PM philmoz ***@***.***> wrote:
Is there an existing issue for this problem?
- I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
@3djc <https://github.com/3djc> discovered that color and B&W radios
handle the Input Source field differently - they apply different filters to
determine which sources are actually value for an Input.
Color radios use a function called isSourceAvailable(), B&W use
isSourceAvailableInInputs().
This looks to date back to the initial Lvgl conversion around 2.4/2.5. In
2.3 both used the isSourceAvailableInInputs() function.
The table below shows the difference I can find between these two filters.
Source Color B&W
HELI YES NO
SPACEMOUSE Only if configured on serial port YES
Channels Only if Mix exists for channel YES
TIMERS YES NO
BATT, TIME, GPS YES NO
Telemetry ALL Only if UNIT < DATETIME
Since isSourceAvailableInInputs() was originally used by all then the
color change may be a mistake not picked up.
Or it could be a deliberate change - I don't know the history.
Asking for feedback on how to handle this:
- Do nothing, leave the status quo
- Change color to use isSourceAvailableInInputs()
- Change B&W to use isSourceAvailable()
- Some other solution
Expected Behavior
Consistency between color and B&W radios.
Steps To Reproduce
Compare options available for input source on color VS B&W radios.
Version
2.9.4
Transmitter
RadioMaster TX16S / TX16SMK2
Operating System (OS)
*No response*
OS Version
*No response*
Anything else?
*No response*
—
Reply to this email directly, view it on GitHub
<#4998>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ66KMIAIKWSFX4ZC6KBETZCCAFJAVCNFSM6AAAAABHTZ24ZOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4TEMRWGMYDMMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Are some of those source even possible ?? What happens if you put a timer as a source ?? How is range mapped to -RESX to +RESX. Not even mentioning GPS |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue for this problem?
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
@3djc discovered that color and B&W radios handle the Input Source field differently - they apply different filters to determine which sources are actually valid for an Input.
Color radios use a function called isSourceAvailable(), B&W use isSourceAvailableInInputs().
This looks to date back to the initial Lvgl conversion around 2.4/2.5. In 2.3 both used the isSourceAvailableInInputs() function.
The table below shows the difference I can find between these two filters.
Since isSourceAvailableInInputs() was originally used by all then the color change may be a mistake not picked up.
Or it could be a deliberate change - I don't know the history.
Asking for feedback on how to handle this:
Expected Behavior
Consistency between color and B&W radios.
Steps To Reproduce
Compare options available for input source on color VS B&W radios.
Version
2.9.4
Transmitter
RadioMaster TX16S / TX16SMK2
Operating System (OS)
No response
OS Version
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: