Skip to content
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

feat(color): support PPM_US setting #4987

Merged
merged 2 commits into from
Jun 2, 2024
Merged

Conversation

philmoz
Copy link
Collaborator

@philmoz philmoz commented May 11, 2024

Fixes #4977 and #3163

I've tried to match all the places that the PPM_US setting is used on B&W radios.

Channel monitor. Note if using PPM_US setting the value at the right above each channel changes to % instead of showing us value.
screenshot_tx16s_24-05-11_14-40-39

Custom failsafe settings:
screenshot_tx16s_24-05-11_14-41-11

Outputs list (min/max values):
screenshot_tx16s_24-05-11_15-11-22

Outputs widget:
screenshot_tx16s_24-05-11_14-47-50

@pfeerick pfeerick added color Related generally to color LCD radios UX-UI Related to user experience (UX) or user interface (UI) behaviour labels May 14, 2024
@pfeerick pfeerick added this to the 2.11 milestone May 14, 2024
@philmoz philmoz force-pushed the color-ppm-us branch 2 times, most recently from 25b34ed to 1eb3e3c Compare May 21, 2024 06:48
@pfeerick pfeerick self-requested a review May 30, 2024 07:32
@pfeerick pfeerick changed the title feat(color): support PPM_US setting on color LCD radios. feat(color): support PPM_US setting Jun 2, 2024
@pfeerick
Copy link
Member

pfeerick commented Jun 2, 2024

This looks to be perfect on TX16... thank you! 😍

Not related to this PR implementation - do you think the Override special function being a percentage (-100 to 100) is inconsistent when the system is configured to be using us? It is currently this way across to the board... 🤔

@pfeerick pfeerick merged commit 43afacf into EdgeTX:main Jun 2, 2024
44 checks passed
@philmoz
Copy link
Collaborator Author

philmoz commented Jun 2, 2024

Not related to this PR implementation - do you think the Override special function being a percentage (-100 to 100) is inconsistent when the system is configured to be using us? It is currently this way across to the board... 🤔

Possibly, and there are probably other places as well.

To be honest I don't use this and personally don't see the advantage of seeing value this way, so I'm not sure where else it should apply.

@pfeerick
Copy link
Member

pfeerick commented Jun 2, 2024

I think the advantage is that it is the actual value sent... and is not relative to anything... -100% - 100% of what / relative to what? 1000ms-2000ms? 988-2012ms? As sometimes this does matter... this is why outputs to BF are supposed to be scaled -97.7 to 97.7 ms... so it is exactly 1000ms - 2000ms, which then feeds in the FCs mixing, Then you have servos that have much broader ranges, such as 360 and continuous rotation servos... so sometimes it is very necessary, but is also somewhat a niche/legacy thing. Personally I've had no use for us outside of needing to set the limits exactly for some FCs, but I'm also not a pattern flyer or sailboating person either 😆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
color Related generally to color LCD radios UX-UI Related to user experience (UX) or user interface (UI) behaviour
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Colorlcd - add us as a PPM Unit option
2 participants