ESC, Devo, BLHeli "magic numbers"

I'm getting into trouble and google is not being friendly.

In the old days, we had 1000 uS to 2000 uS PWM signals transmitting 0 to 100. Percent of something. Tinkering around with everything that could be twisted, turned or slid got full throws on servos and such like. (Trimming was mechanical! And worked well.)

So.

Why does deviation use -100% - +100% to output 1100 to 1900 as seen in, say, the Betaflgiht configurator? I happen to have an (*as yet) unmodified Devo 12E, its first model displays 0-100% but also yields 1100 to 1900.

In deviation, a simple mixer has two places where a scale of 125 can be put in, either -125 and +125 in the first part or scale 125 in the second part. Either then gives 1000-2000 in Betaflgiht. This makes mathematical sense, at least.

Is there any reason to do it it one place or the other? What means 125% in the digital realm? I assumed there was a digital number being sent. How many bits is it and does it correspond in any way to old fashioned uS? What would be the range of the number? If this is protocol dependent, just give me a "for example".

Last but by no means least, I note that BLHeliSuite has defaults of 1148 and 1832 for the PPM settings, with a midpoint of 1488. Frankly I find these mystifying if not offensive!

Actually now really last, the simple ESC calibration recipe I have followed when I don't use BHS is to use the Betaflgiht configurator motor section and dial in 2000, power up, wait for the tunes and dial back to 1000. I was of the impression that this would set the ESCs to 1000-2000.

It seems in the digital realm with accurate enough clocks on all processes that calibration wouldn't be an issue as would not some of these other things that may be at the bottom of the problem I am working on now, which I am not sure isn't a misunderstanding on the deviation side:

With everything looking very good Betaflight-wise,

(motor section 1000 to 2000 runs motors up smooth, they all start around 1070,
throttle looks smooth 1000-2000 in the receiver section,
no air mode, same behaviour acro, horizon or level) viz:

When I finally arm and try I get no motor action until I crack the throttle open past min_check (1010), at which point I seem to get some very large and uncontrollable RPMs.

But never mind that unless you see something I could try. I really just want to learn about this 1000/1100/1148 thing.

TIA

crash7X

Some of us find the rxrange command in Betaflight helps even out the numbers. I used:
rxrange 0 1159 1841
rxrange 1 1159 1841
rxrange 2 1159 1841
rxrange 3 1159 1841

This sets the 1159-1841 range of my Devo to equal the 1000-2000 range that Betaflight wants to see. Those are the only fidgets I need to do and all the other normal Betaflight defaults work straight away.

YMMV. Happy flying!

Deviation uses -100 to +100 on each input, with 0 as a center point, as (I believe) any stick etc can be configured for whatever the hell you want it to be; just because the throttle stick is normally the throttle doesn't necessarily mean that it always is, and doesn't always mean that it's a positive 0-100%. So for consistency.

I'd say the 1000-2000 thing depends on protocol. I think I recall always reading about Spektrum TXs needing to to 125% on throws to get the full range, so I'd imagine the developers just followed on from what's been established?

I think the different places for defining scale etc. may have to do with mxing and clipping, eg. one's a hard limit on how for the TOTAL of the mix can go, so if you have something scaled 150% and blended with another input scaled at 125%, you only ever max out at 1000-2000?

Deviation never outputs PWM signals, It will output PPM to the trainer port if you select PPM output, and there you get to set the pulse width, etc. that is used.

The PWM values you are seeing are created by your receiver, not deviation. The value communicated between deviation and the Rx depends on the protocol. We probably aren't consistent about translating between percentages and those values across protocols, but given that the translation from those values to percentages isn't consistent across protocols or receivers, I'd say it's not worth the effort.

Crash7x is correct about the different places for setting scale being clipped differently. In answer to your other questions:

What means 125% in the digital realm?

It varies depending on the protocol and receiver.

I assumed there was a digital number being sent. How many bits is it and does it correspond in any way to old fashioned uS?

The number of bits depend on the protocol and possibly the channel number. The correspondence to uS depends on the protocol, the Rx, and in some cases may depend on the mode of a combined Rx/FC board.

What would be the range of the number?

Well, beyond the limits of the # of bits, it depends on the protocol.

If this is protocol dependent, just give me a "for example".

From the FlySky protocol (because I happened to have it open):


Bottom line is that this is a mess - everybody does things slightly differently, and we haven't even looked at different servos/ESC's/etc yet. Deviation gets exposed to it all because it works with so many different implementations.

Your best bet is to stop using bit-banging protocols like PWM and use a proper digital protocol like SBUS. All the consistency issues vanish, the frame time gets shorter, the issues with frame overflow vanish, there's less load on the CPU, and so on.

mwm wrote: …

Your best bet is to stop using bit-banging protocols like PWM and use a proper digital protocol like SBUS. All the consistency issues vanish, the frame time gets shorter, the issues with frame overflow vanish, there's less load on the CPU, and so on.

Hear that. Thanks all for the info. Do I "know" that the FC -> ESC control is now the last synthesized signal, slowly going away with the advent of DShot?

c7