This is exactly what is wrong. The pilot determines how much input he/she wants, not the simulator. If I want 100ms or 200ms of input it should act accordingly, not wait to see if I’m still holding the button so then it releases the trim movement. This is absolutely wrong.
1 Like
If I understand it correctly @CasualClick is talking about the delay in aircraft response, not the trim input.
I mostly agree with that.
But I also see the programming challenge on a joystick button that has no inherent ‘repeat’ functionality. This means the sim programmers had to come up with some kind of solution. The annoyance is that they did not open this up through settings. It would be cool if you could determine per button how it should respond. E.g. have an option to say ‘repeat without delay’…
But the problem with a button will always be that you cannot steer the ‘timing’. With a wheel you can go quick or slow. With a button not (although you could consider using timing again… go faster the longer you keep it pressed). It really needs the settings you have in Windows for the keyboard repeat (go fast, go slow, delay short, delay long).
And… I’m not assuming this… but if it’s really sloppy programming work, the delay could even differ per computer (if they are not using a reliable timer).
Response delay is very important for FPS games potentially impacting results. There was a study done checking the response delay between button press and the screen update. I think lag was measured for certain brands of mice. The testing concluded that there are lag differences between different brands. Not all hardware is 5he same.
I also have a Thrustmaster Hotas Warthog and have no delay.
How do you assign the button for trim? Direct in MSFS, FSUIPC or Spad.Next?
The aircraft responds to the trim. The delay is self-imposed to see what it’s doing. I could keep spinning the Trim Wheel full revolutions but all that will do is configure the aircraft incorrectly because of gross inputs. There is no delay between my moving the wheel one notch or ten or even a full revolution, the trim wheel in flight responds. The aircraft will also respond accordingly, but is there a reason you’re not waiting to see what that trim input did, and if it was enough or it needs more?
Direct to MSFS, I don’t know any other way.
I didn’t undesrstand your question. The delay I’m complaining is directly noticeable in the trim wheel, not the aircraft response.
The delay I’m complaining is clearly something from MSFS, I don’t have it on any other sim, like il-2 or DCS
Have you tried disconnecting your joystick and check if the trim delay still occurs if you are using the keyboard?
Yes, it behaves the same way
Really strange. They only other thing I could think of (but rather improbable) is a low frame rate which might cause a delay.
I’m running MSFS with fixed 30fps
I’m running above 60.
Hi all I must admit I have never attempted such a project before so any help is appreciated.
I already have a spare 10" monitor and plan to build my own trim wheel to something resembling this and I really need as many pointers as I can get (the 152 cockpit is just an example).
As you can see ideally I would wish to incorporate the trim gauge to the screen. I am already aware there can be problems with autopilot changing elevator trim which is something I hope to avoid by using a hall effect 360° rotor although I’m not sure what happens once it goes beyond 360° or below 0°, do the numbers keep climbing? are negative numbers even possible? and the biggest question of all, can MSFS dictate to an arduino as to where the elevators actually are and change parameters accordingly? Does it even need to? (Can the Arduino query this as soon as the wheel is touched and change parameters itself? or maybe put the autopilot master switch on it)
I would try to find a device sending discrete up/down pulses like the trim wheel on the Honeycomb Bravo. This eliminates the autopilot issue completely.
@ €300 a pop the honeycomb is not an option when with the right knowledge I can build what I want for a tenth of that.
Edit: there’s also a lot of satisfaction that comes with DIY.
I didn’t mean to suggest that you get a Bravo, although I can see why you would think that.
Just used it as an example of a device that works with discrete pulses rather than axis positions.
1 Like
Don’t worry I wasn’t taking offence. The facts are that being vulnerable I haven’t worked regularly since the start of covid (i.e. I’m skint) but also that I enjoy the challenge of making stuff and since covid I’ve become a dab hand with a soldering iron although not so much the science behind the things (mostly speaker systems, LED lights etc.) I am fixing. However I do think I am ready for the next step, who knows where it may lead.
If you’re building your own, a couple suggestions:
- exposing the device as an axis will have problem when you switch off autopilot…
- if you use a rotary encoder with no fixed top/bottom points, use an input manager to detect rotation events and map that to SimConnect events updating the trim by a specific amount (in percentage or angular delta in radians)
If your device exposes a basic gamepad-style USB controller (easy enough with common tools) you can hook that up to spad.next or FSUIPC to do that, or roll your own using SimConnect.
The advantage of this method is that after disengaging AP, you don’t have the wrong (old) position on the axis.
You could also map straight to the trim up/down buttons in MSFS, but then the trim speed is at the mercy of MSFS. 
With SimConnect you can set how much the trim moves for each notch of the rotary encoder.
If you want to go fancy, add a motor and a feedback loop that updates the wheel position when the AP moves the trim.
1 Like
Exactly the info I was hoping for although I’m sure the’ll be much more of the technical stuff … Thanks very much. And “going fancy” is something I definitely hope to avoid for my first genuine electronics project. 
1 Like