Elevator Trim Offset Controls

[John Fee]

I'm using 'Offset SWord Increment/Decrement' to control elevator trim buttons on a yoke in both FSX and FS9 (Windows 7 x64). In the parameter box I set 256/16383 for increment and 256/-16383 for decrement. I allow the control to repeat when the (trim) buttons are held.

My problem is that the resulting trim control is very fierce - it is as though the button was controlling the elevator directly and not just trim tabs. I don't know the correct word for it but I suspect the 'frequency' of signals sent by the button is very fast and that this gives an exaggerated effect. Could this be so? If it could be, is there a way of adjusting the rate at which the button sends its signals when held?

Thanks.

John

[Pete Dowson]

I'm using 'Offset SWord Increment/Decrement' to control elevator trim buttons on a yoke in both FSX and FS9 (Windows 7 x64). In the parameter box I set 256/16383 for increment and 256/-16383 for decrement. I allow the control to repeat when the (trim) buttons are held.

Using which offset?

My problem is that the resulting trim control is very fierce - it is as though the button was controlling the elevator directly and not just trim tabs.

Well, in default aircraft the FS implementation of trim has the same effect as the elevator -- the same range as well.

I don't know the correct word for it but I suspect the 'frequency' of signals sent by the button is very fast and that this gives an exaggerated effect. Could this be so? If it could be, is there a way of adjusting the rate at which the button sends its signals when held?

The most obvious thing you could do is change the 256 incrememt/decrement you are using to something you find more acceptable. Why 256 if it is too much? Try 128 or 64 or 32 or something!

The repeat rate for button scanning defaults to something like 20/sec, but is adjustable in the INI file as documented in the Advanced Users guide.

If you do reduce button scanning, bear in mind that this will affect any rotaries.

Pete

[John Fee]

Thanks. Am using x0BC0 as per the Advanced Users guide.

I thought by reducing the number of increments/decrements this would make matters worse - dividing the same range into fewer, and thus larger, segments. Worth a try.

I don't want to reduce button scanning rate if that's going to affect rotary buttons as well.

Thanks again for prompt support. Hope all well with you.

John

[Pete Dowson]

Thanks. Am using x0BC0 as per the Advanced Users guide.

Good. That is the elevator trim control input.

I thought by reducing the number of increments/decrements this would make matters worse - dividing the same range into fewer, and thus larger, segments. Worth a try.

The 256 in your parameter is NOT "the number of increments"!!! It is the AMOUNT of increment. It means on each button press ADD or SUBTRACT 256. Obviously the trim action will be fast with a larger increment and slow with a smaller one! How did you get the completely wrong idea here? I'm sure it is clear enough that the value for an increment/decrement control is the increment/decrement value.

Pete

[John Fee]

The 256 in your parameter is NOT "the number of increments"!!! It is the AMOUNT of increment. It means on each button press ADD or SUBTRACT 256. Obviously the trim action will be fast with a larger increment and slow with a smaller one! How did you get the completely wrong idea here? I'm sure it is clear enough that the value for an increment/decrement control is the increment/decrement value.

I quote your guide:

'The 256 is the increment and 16383 is the limit. This will give 128 steps between -16383 and 16383 inclusive (32768/256 = 128)....'

The word 'steps' is how I got the wrong idea. I understand now that my interpretation was incorrect.

John

[Pete Dowson]

'The 256 is the increment and 16383 is the limit. This will give 128 steps between -16383 and 16383 inclusive (32768/256 = 128)....'

The word 'steps' is how I got the wrong idea. I understand now that my interpretation was incorrect.

Yes, because that says 256 gives 128 steps. 128 would give 256 steps (32768/128 = 256), so obviously each step would then be smaller. At the extremes 1 would give 32768 steps, and 32768 would give none. (well just the one you are on). ;-)

Pete