This feature is super useful for a lot of servos that use extended range PWM.

This has a lot of things that needs fixing, mainly the config struct can't just be changed like that, and the way this is calculated loses even more source resolution. I don't have time to get into it now though.

To work around the former, does anyone actually use that 750us mode? Is that even a thing? I added it because when I wrote all the PWM stuff one person said to me "Can you make it so the pulses are half as long?" and I had never heard of that but I threw it in because everything was new then so it was easier than it would have been to add it later.

If 750us isn't a thing, then we could just use that bit for this and save a lot of headache/code. Does anyone know if that can be removed?

config struct can't just be changed like that,

Actually I made it so that anybody else migrating from the old struct will still have their settings be effective until the next time they use the web interface to configure. I also have never heard of a practical use for 750us mode and would agree to simply turning it into a stretched mode. But how do we make sure

the way this is calculated loses even more source resolution

I can easily change this such that the calculation happens in the same place where CRSF_to_US used to happen so we preserve as much resolution as possible.

Yes its useful for plane pilots who are switching to ELRS
#2522

To work around the former, does anyone actually use that 750us mode? Is that even a thing? I added it because when I wrote all the PWM stuff one person said to me "Can you make it so the pulses are half as long?" and I had never heard of that but I threw it in because everything was new then so it was easier than it would have been to add it later.

If 750us isn't a thing, then we could just use that bit for this and save a lot of headache/code. Does anyone know if that can be removed?

I mostly fly LOS fixed wing and heli, and I don't think 750us is really a thing outside of yaw servos for RC helicopters (which generally use a flight controller anyway), and probably some specialized cases that I can't think of. I'm not aware of any other radio system in the hobby with a PWM receiver that can support the 750us servo operating range. I'm sure one person will be upset if it gets removed though, haha!

It's also useful for Drag Racing and similar folks who like to turn their rates up to 125% to "Get a little extra power and speed" out of their systems supposedly.

if narrow mode is 500-1000 anyways, and the new stretched mode is 500-2500, can we assume that anybody who used to use 500-1000 can simply edit their mixer since those ranges overlap?

as far as I can tell, the resolution will be similar and it's not like using 500-1000 increases the update rate anyways, the PWM generator's frequency never changes.

Why add non standard 500us-2500us PWM when standard 150% 732us-2268us is not supported and EdgeTX only supports 150% max anyway.

Why make stretched non standard pwm mode for ELRS?

The goal is to help people save money, save space, and save weight, by avoiding products such as this servo stretcher, or this (example 2), or this (example 3), or this (example 4), or this (example 4). These products exist because of the limitations of older receivers and old standards, while EdgeTX itself is not to blame, this is going to provide an option to mitigate that old constraint.

The last commit I just did replaced the narrow flag with the stretch flag, and I think it could work as an implementation that satisfies everybody, even people who were previously using the narrow flag. I have also resolved the resolution issue and now it should have as much resolution preserved as possible.

Please review, thanks!

Then why not add standard 150% 732us-2268us.
100% and 120% modes are allready supported in ELRS.
Allmost all radios support 150% mode.
And most 3D pilots use 150% mode to get full travel without using longer servo arms.

It seems there are different requirements for different pwm range, so why not add mixer support so that people could config custom pwm range. (I just like a Mixer Salesman. Orz...）

on the other hand, I could understand that the requirement for custom pwm range is not so widely(compare to the amount of ELRS users), and it would make the pwm out a bit more complex.

This is a great feature to add. With more adoption of ELRS in planes, combat robotics, rc cars/trucks/crawlers since the RM MT12 was released, this is the time to get this added. We need to get this reviewed please!

I could really need this as well. I'm would really love using the full range of my servo.
What's the current state of this?
What's left to do?

seems to work from my initial testing, the servo does indeed go twice as far, to the full 270 degrees

Found this PR while looking for how to enable double pulse width that's already mentioned in the docs. Tested the PR and it does indeed work.

I agree with all of your comments,

A standard 150% 732us-2268us travel is needed for steering servo to have the full steering angle without using longer servo arms (rc car racing)
And in a low latency mode (333hz or even better F1000 mode)

Will the feature ever be merged?

Alright so looking through the comments on this PR and our existing system it seems like this could have a dose of scope creep. We seem to have a desire for:

• 100%: Normal. what it looks like in EdgeTX is what you get. Normal res 988-2012us, Fullres 855-2115us
• 150%: Endpoints are scaled to 732-2268us (150% EdgeTX). Normal res just gets 150% multiplier. Fullres mode is scaled from the fullres endpoints, not from 988-2012,
• 200%: Endpoints are stretched to 500-2500. Same fullres rule.
• Half width: same as normal but the pulse width is halved (existing "750us" mode)

Is 150% needed? I bring it up because if we just do 200% then we're scaling up our 10-bit value so each bit is 2us, then the user might adjust their range down in EdgeTX which throws away part of the 10-bit range and make it even more chunky.

Am I overthinking this?

I vote for only having 100% original and then a 200% mode. Anything in between can be done by adjusting EdgeTX parameters, as you said.

Thanks for weighing in @frank26080115 we're looking to move on this as I have time this week or next. Two things I can see that need to be addressed, but I can handle them when I review:

• The failsafe should not be stretched. We are updating to support failsafe ranges 476-2524 and the failsafe values are absolute
• And uhh I can't remember the second one now, I think we decided to not reuse the same bit in the config but we'll address that at the time

I would've liked Ncerzzk's implementation so that you wouldn't have to second guess what the users would want. It's like setting subtrim and extents on the aircraft so that you can make full use of the 10-bit resolution. I'm in the 150% camp because of the micro servos I'm using (200% hits the hard stops), but I don't know how common that is.

Instead of adding different scaling options; how about a travel scale value for PWM channels that defaults to 100% but allows scaling up to 200% ?

I would've liked Ncerzzk's implementation so that you wouldn't have to second guess what the users would want. It's like setting subtrim and extents on the aircraft so that you can make full use of the 10-bit resolution. I'm in the 150% camp because of the micro servos I'm using (200% hits the hard stops), but I don't know how common that is.

The problem with just accepting any endpoints is that they're locked in once the configuration defaults are set, which means everyone gets 988-2012 regardless of if they are using a normal or fullres packet mode (which supports 120% range). There's just too many things to set and it is way too cumbersome and not at all obvious to users, who will think that no matter what they do they can't get anything but 988-2012 out of the system unless they go into the webui. As it is currently, just changing the packet mode to fullres gives you the larger range with no other faffing about with the ExpressLRS config.

The stretch mode will just map whatever the input range is to the 474-2526 endpoints. I find all of this to be a complete mess because no matter what, a decent percentage of users are going to be confused at the behavior regardless of what system we use 😅 There's just too many layers each of which is configured from a different area Sticks -> Inputs -> Mixers -> Outputs -> ELRS Packet Mode -> Endpoint Stretch...

Certainly fair. I wondered why the "full" switch modes would change the PWM scale on the receiver: it's 10 bits either way, so it felt like it should be a receiver setting regardless of switch mode. However, ELRS is now popular enough that rocking the boat can get pretty ugly for the "turn-key" end users. As a software engineer, I understand the pain of living with a design decision made years ago that can no longer be undone.

Stick with the 100%, 200%. I don't "need" 150%, and if I get desperate enough I can always implement it in a private build. No point adding complexity to this feature until a decent number of people demand it.

Just an update that this hasn't fallen off the radar. It's been a busy week but our internal plan has this on it and the merge deadline is Nov 16, although I will work to have this approved sooner than that.

I've merged master back into this and brought it up to date with the v11 RX config changes. Changed a many other things as well

• Failsafe values are not stretched any more, the new config supports extended failsafe ranges all the way to the stretched value so just put what the failsafe value is
• Using the lua's "Set Failsafe Pos" command will use the current stretched/inverted positions
• In fullres modes, the value is stretched from the fullres limits, not the standard limits. This increases the precision of the output value by ~50%
• Stretch goes from 500us to 2500us, not 474-2524us
• The "narrow" config item should not be migrated into the "stretched" config item
• Fixed compile error w/ DEBUG_LOG, and uninitialized compare when setting