Thread Tools
This thread is privately moderated by Miami Mike, who may elect to delete unwanted replies.
May 27, 2018, 05:43 PM
e^(iπ) + 1 = 0
Miami Mike's Avatar
Thread OP

The Big OpenTX Trim Mess

There's a bug in the trim steps and trim limits in OpenTX that has apparently been around for a long time, and which I reported on Github back in February of 2017.

Briefly, trims have a maximum integer value of 250 instead of 256.

256 is 2^8 or two raised to the eighth power, and would be exactly 1/4 of the maximum integer value of 1024, which is 2^10 or two raised to the tenth power. But 250, which is 2 x 5^3 or two times five raised to the third power, is 24.4140625% of 1024. In the midst of a system neatly based upon powers of two, there's an awkward and illogical value that's the cause of a big mess!

This appears to have been the result of a programmer confusing the percentage value of 25% with the integer value of 250, and in OpenTX version 2.1, one of its consequences is an odd behavior that I described to the developers in an attempt to prove my case:
Here's an oddity that fixing this bug will cure: In any trim step setting beside "Extra Fine" (2 steps per click), the values accessible when you start from zero are interleaved with the values accessible when coming back from maximum or minimum. For example, if your trim setting is "Fine" (4 steps per click) then if you start from zero you can select settings that are multiples of 4, such 4, 8, 12, 16, etc.

But if you go all the way to the current unintended limit of 250 and come back, you can only get to settings that are equal to 250 minus a multiple of four, such as 18, 14, 10, 6, etc.

Increasing the trim limit to 256, as it was almost certainly intended to be in the first place, would clear up that problem.
The reason version 2.1 behaves like this is that when the next step would exceed the limit of 250, the setting is instead set to exactly 250, and on the way back to zero, when the next step would jump over the value of zero, it's set to exactly zero. This is what causes the interleaving effect.

I took a look at OpenTX version 2.2 to see if they'd done anything about it and I found that all they've accomplished since then was a half-hearted workaround. They've eliminated the feature where, when the next step would exceed the limit of 250, the setting was instead set to exactly 250. Instead, when a trim step would exceed that limit, it doesn't change at all. The result is different limits for different settings of Trim Step:
Trim step 	per step	limit	  percent
Exponential	   -		 234*	22.8515625%	
Extra Fine	   2		 250	24.4140625%
Fine		   4		 248	24.21875%
Medium		   8		 248	24.21875%
Coarse		   16		 240	23.4375%
What a messy and unnecessary workaround! The whole problem would go away if they'd just set the limit to 256 instead of 250.

But there's another problem that might take more than just setting the limit to 256, and it involves the Exponential Trim Step setting. This problem exists in 2.1 and still exists in 2.2: With Trim Step set to Exponential, rocking the trim switch up and down, or left and right, causes the value to jump all over the place in such a way that there's no easy way to get back to the value you started with. For example:
  • Go all the way up to 234 = 22.9%.
  • Click down and it'll go to 174 = 17.0%.
  • Click up and it'll go to 218 = 21.3% and won't go any higher.
  • Click down and it'll go to 162 = 15.8%.
  • Click up and it'll go to 204 = 19.9% and won't go any higher.
  • Click down and it'll go to 152 = 14.8%.
  • Click up and it'll go to 192 = 18.8%, and in this case you can click again and it'll go higher than 234 to 242 = 23.6%! That's the reason for the asterisk in the table above. You can actually make the trim go farther by jiggling the switch a few times.
You probably get the idea: The developers put a band-aid on the trim settings issue but what it really needs is a major operation.

And by the way, please don't tell me to report it on Github, I've been there and done that.

Sign up now
to remove ads between posts
Jun 04, 2018, 12:53 PM
Sagitta Fanboy
I'd suspect the root of this is from the joy that is signed integer arithmetic.

First off, I'd doubt the actual max value in a channel is 1024. It's almost assuredly +1023 (with a minimum value of either -1023 or -1024 depending on implementation). That's an 11 bit value with 2048 resolution (remember, zero is a valid value).

If the trim settings are a separate variable, they're probably a 9 bit variable. That gives a range of -255 to 255 (or -256 to 255) depending on signed implementation.

250 is a valid limit, although given the even gradations in use, you could go as high 254 without any real issues.
Jun 04, 2018, 02:02 PM
e^(iπ) + 1 = 0
Miami Mike's Avatar
Thread OP
No, they go from -1024 to +1024 with zero exactly in the middle of the range. You can see it in the GVAR limits in OpenTX 2.2, and Lua scripts deal directly with those integer values. -1024 equals exactly -100% and +1024 equals exactly +100%.

I understand what you're thinking about signed integers, but a one-byte signed integer would have a range of -128 to +127, and a two-byte signed integer would have a range of -32768 to +32767. I assume the original developers considered the former to not have enough resolution and the latter to have too much, so they chose a range in between and configured it for perfect symmetry.

And if you were right about trim settings being stored in a 9-bit variable, that would take up two bytes per value with 7 bits wasted. If they used 10 bits instead of 9, they could have a neat and elegant range of -256 to +256 in the same two bytes per value with only 6 bits wasted.

But that doesn't appear to be the way trims work. If you read their values with a Lua script, you'll see that they actually cover a range of -1024 to +1024 if Extended Trims is not checked, and -4096 to +4096 if [i]Extended Trims is checked. Apparently a translation of that value takes place elsewhere in the system, and that seems to be where the bug lies. If you have Extended Trims checked, the trims can cover a range from -1000 / 1024 = -97.65625% to +1000 / 1024 = 97.65625%.

Doesn't it seem a bit odd to have an extended range of -97.65625% to + 97.65625%? It's a bug.
Reads the aileron trim integer value and
displays it on the Debug Console Output screen
local function init_func()
local function run_func(event)
return {run=run_func, init=init_func}

Quick Reply
Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion opentx with big planes martinwh99 Radios 1 Jan 26, 2015 06:01 AM
Discussion Big Brother is messing with your PC dll932 Life, The Universe, and Politics 212 Oct 27, 2007 12:06 AM
Cleaning a Big Mess... Help Me!!! dchomie87 Car Talk 5 Aug 26, 2005 10:01 PM
don't want to start a mess - "big" electric question dgoss Electric Heli Talk 4 Feb 19, 2005 02:21 AM