Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.
You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks!
The community support for MobiFlight has moved exclusively over to our Discord server. Register for free and enjoy more interactive functions like image and video upload, voice chat. More than 7,000 registered users around the world make it a great experience!
A HUGE Thank You to everyone who participated in the forum, especially obviously to Pizman and Stephan who did an outstanding job over so many years providing an incredible service to the MobiFlight community.
The forum is still providing a lot of good content, hence we keep this information accessible.
Index > MobiFlight Projects > Trim Wheel Values1 23
From: Hamburg, GermanyMy favorite plane in FSX is the stock A321 and i'm building / planing a "low cost" and not fully real cockpit.
I want to build a trim wheel (i have a 3D-printer, so mechanics is almost done) but i'm not quite sure how to control the wheel.
I know that under normal conditions the wheel won't be touched by the pilot, but it moves (but not on the screen ) and is good looking.
On a swiss page (tough to read, as they write like they are talking. wow) i found that the wheel makes a little more than 8 total turns for the full range.
And in the FSUIPC docs i found the offset 0BC2 (Elevator trim indicator (follows input)) and i assume that the value here could be something between -16383 and +16383.
Am I so far right?
If so, how would be the formula to convert this value for a "standard" Stepper (28BYJ-48)?
[Last edited by kjoussen, 2022-01-06 22:17] 2022-01-06 22:09 Whiteknuckle157 From: Bayern - Bibertal, GermanyI'm literally right now working on a generic motorized airliner trim wheel.
Objectives are: Wheel to be controlled manually normally and controlled by motor when in autoflight/autopilot mode (pitch/altitude control).
You may contact me via discord
2022-01-07 14:29 From: ETSI, Germany Posts: 6010Supporter
The Trim Wheel is a "problematic Part" Cause it have "more then 360° Range !
The master Problem: We can not move a Motor aslong it isunder power. For sure we can build e.g. a logic like "IF AutoPilot is ON, then Run the Motor. if Not, Disbale it.
BUT. Here a "Stepper" no longer work. Cause a Stepper only know it´s position by count every "step" it move.
For example if we start the Stepper at Value "0" . While AP is on the Motor is moved to "500" . So Stepper "know" it is at 500!
If we no disable it and move the Wheel by hand ( e.g. to 300 Position) AND now we engadge the Stepper again. then it "think" it is still at 500 whatever it is at 300 !
We can build a perfect system that show a pure Output. So a Trimwheel that NOT is controlled by hand !
If we like to trim manually we do this by use the Buttons on the Yoke e.g.
Otherwise. If we like a combine IN/OUT System. then pretty sure a Stepper is the wrong idea.
Then we need a Encoder and a simply DC Motor. And also "there" it cet difficult in case there must be a "initialise Calibration".
The System only work if Trim Wheel in Sim is in "zero Position" at startup.
Maybe a good compromise is a FAKE Moving.
So the Wheel not show a correct Position ( e.g. between 8x360° Turns) . We can say e.g. IF Virtual wheel is turned, then also turn real wheel for xx steps.
So no 100% real position. More a simulated movement if AP is trimming. But not correctly e.g. 10,20 or 30° Just a impulse of xx° every time the Sim Trim Value change.
The only way i see for a 100% accurate Turning. Using a Cogwheel System 8:1
So 8 turns of Wheel occure in ONE Turn of a 360° Poti ( or e.g. 12 Turns if Poti is just 270°)
THEN we have a clear Position indication and a posibile calculation of Wheel Pos and Sim Pos.
*******************
Summary: For a Throttle ( maybe 90° Movement) this works fine. But for Trimwheel i currently not see a "perfect" way !
At last: Ask yourself. Will/need you to trim by moving the wheel. Or is the Button on Yoke already fine? Cause then its no big deal to build this !
Good Luck !
2022-01-08 01:45 Whiteknuckle157 From: Bayern - Bibertal, Germanyas stated above, I'm working on a trim wheel system right now. Just waiting for a part to be delivered today.
The range is not the problem at all in this case. The trim wheel drives a 10:1 geared potentiometer. I used this setup for years before. The second part is the servo consisting also of a geared 10:1 potentiometer driven by a geared (100rpm) motor controlled by an Arduino (Uno or Nano) via an H-bridge. This servo is independant and gets its target value from the mobiflight trim position servo output (since, alas, Mobiflight cannot communicate to other Arduinos by default). This unit is swiveled and can be connected to the wheel with a Sg90 Servo. Also via Mobiflight signal (Autopilot engaged or the like). While not connected to the wheel, this servo/poti-unit always follows the value given by the trim position output. The wheel is driven manually and the potentiometer gives its value to the system via Arduino Micro Joystick setup.
When the Autopilot is engaged, the Sg servo tilts the unit and connects it to the wheel. The wheel is now driven by the motor. Here you may see the 3D-model:
I have the mechanics ready so far and hope to be able to report soon if it either works or fails.
2022-01-08 09:16 From: ETSI, Germany Posts: 6010Supporter
Thats what i say. A SERVO know it´s position or better it can be driven to a specific Position !
A Stepper not do this. It remains its position by counting the movemnets since systemstart. So here a Hand Move is simply not possible.
Why i think about a standard DC. A Servo ( whatever unpowerd by e.g. a Relais) can be problematic if you move it by hand.
I not know Whiteknuckles Hardware. But e.g. the small Servos we normaly use are Broke in maybe 1 of 3 cases if you try to move the needle by hand. A little better if Servo is out of power. But still a high risk in case there is just a little gearbox from plastic. Simply not designed for a Hand moving !
So. The Difference of the 2 Logics:
Servo: It know the Pos. So its pretty sure simply "out of Power" while Hand-Use . Means the Poti in the Wheel is the INPUT . The Servo is the OUTPUT.
To avoid a "Conflict" i think it´s also needed to disable the Poti aslong the AP is active and the servo workes. Without that, the Poti will "overwrite" the Servo Inputs by own Inputs via the Joystick Axis to the Trim !
DC:
Here we would make a comaprison between the 2 Values.
For INPUT ( AP Off) the Wheel is moving free (clutch between motor and Wheel if we need a overwrite. If not also the clutch is not needed). The Poti simply is a Input !
For AP ON We simply read "Position of the Poti" and "Virtual Position of Trim"
Lets say we rework both to have a Value of 0-16383
Now we Subtract One of the other. E.g. Current Poti Pos MINUS Virtual Trim Value !
If both are sync on same place . e.g. 5000-5000=0 then the result is always Zero !
If the Real Wheel is on a other position ( e.g. when the AP move the virtual one for a half turn) . Then our Calculation occure in a Value.
+xxx if the wheel is e.g. "Above" the needed Position. or -xxx if it is "below" the target position.
With THAT information we can build now the Motor Controll logic!
The Motor must work if the difference between both Values ( Wheel and Sim) is greater then xxxx
And we decide the direction of the Motor, by check if the "difference" is greater or less then 0
In easy words. If both are sync, our system "sleep" . If not it start the motor in that direction the "target" is. And it stop it automaticly when the two values are sync again ( means when the wheel reach the position of the virtual one.
Last Note: This logic work fine for a Throttle. But maybe is a little harder for this 1:10 system. Pretty sure not verry smotthe !
May Whiteknuckls Idea with a Servo is better. Aslong you can handle the Hand Moving without destroy the machanics !
Good Luck !
2022-01-08 12:42 From: Hamburg, Germanyafter i understood the 3D-Model and how it works. nice. i hope your tests are going well and you share your STl-Files for it.
Second, although this design is really nice, it is no answer to my question.
I'm more into the fancy moving thing. In the case i have to change the elevator trim manually i have a two way push button as well.
As long as there is no defective part in the plane, the typical Airbus pilot never touches the wheel but changes the trim value over the FMC.
Whiteknuckle157:Hi,
I have built the system and had it perform some tests. It works in general but there are some things to work out.
I intended to control the servo motor with an Arduino Nano. This works fine as long the target value is provided with a geared 10:1 potentiometer connected to an analog input. This works smooth and flawless as standalone.
Since Mobiflight does not provide a direct communication to the controller, the only means I'm aware of so far is the Mobiflight servo-output which works with a PWM signal. I can sense this signal with the Nano and can control the servo motor accordingly. But, alas, this signal is extremly jittering hence the whole system is very unstable. Therefore I resorted to a relatively powerful RC model servo (20Kg metal) electronic, ripped it out of the RC-servo and used it instead of the Nano, connected to the tilting assembly (Lever) with the servo motor and the second geared potentiometer. This works very smoothly.
The trim hand wheel controls the geared 10.1 potentiometer connected to the flight simulator via the Arduino Micro joystick controller as usual. This works fine. Mobiflight provides the elevator trim value as a servo output to the servo system. This is running, mechanically disengaged, in sync with the manually driven trim wheel. Hence both geared potentiometers should always have the same values. At least, in an ideal world.
When the Autopilot is engaged, most aircrafts shall be in attitude hold mode. This also includes the elevator trim function. Once engaged, the Sg90 servo tilts the trim servo motor lever and engages the gears. Now, when the elevator trim is actuated by the autopilot, Mobiflight provides the trim wheel position and the servo rotates the trim wheel.
Caveat!
With the trim wheel, the servo motor also rotates the trim potentiometer. I am suspicious that this might lead to some unwanted effects due to interference. The signals from the internal autopilot and the trim wheel might either cancel each other out or, worse lead to severe oscillation or runaway. Hence either the system ought to be thoroughly tuned in or the mechanic may be redesigned to disconnect the trim potentiometer also while in auto mode.
I tested this with the default FSX-SE C172 and it works quite fine. It did not work stable with the FXS-SE B737-800. There the system had a runaway. That is the reason I believe that the internal autopilot trim value and the manual trim value add up.
Since the elevator trim wheel does not have markers that provides absolute wheel trim position (this is provided ba a separate gauge), it might be a good idea to disengage the trim wheel potentiometer from the wheel when autopilot and servo are engaged. This will let the trim potentiometer not interfere with the servo system and the automatic. To do this, I ought to redesign some parts of the assembly. Since I intend to have the stl files for download, I'm somewhat undecided if it makes sense to publish the parts in the actual state or wait until redesign is finished. I will happily consider your opinions.
I will also be on Discord most evenings and may be contacted there.
Kai: this setup will work fine for your purpose. Just omit the trim wheel potentiometer and the sg90 servo and have the servo motor lever always engaged. In this case this works as a gauge. The geared potentiometer controlling the servo motor provides ten full turns.
