This thread is privately moderated by Miami Mike, who may elect to delete unwanted replies.
May 27, 2018, 06:43 PM
400' is a bad winch launch.
Rant

# 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:
Quote:
 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:
Code:
```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.

 Jun 04, 2018, 03:02 PM 400' is a bad winch launch. 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. Code: ```--[[ Reads the aileron trim integer value and displays it on the Debug Console Output screen ]] local function init_func() end local function run_func(event) print(getValue("trim-ail")) return(0) end return {run=run_func, init=init_func}``` Latest blog entry: List of Threads About HR 302