MobiFlight Community Support

Gooed evening.

My 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)?

Thanks

Kai

Hello Kai,

I'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

cheers

Volker

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 !

That means....

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 !

Hi,

as 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:

https://myhub.autodesk360.com/ue28b04f1/g/shares/SH9285eQTcf875d3c53994262109b7d3a5df

I have the mechanics ready so far and hope to be able to report soon if it either works or fails.

Cheers

Volker

Yes....

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 !

Hi all,

after 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.

Kai

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.

Cheers

Volker

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.

May i missunderstood.... But i think we talk about different things.....

If the wheel is just a OUTPUT ! .... We have no Problems at all.
So if you controll the Trim just by the buttons on your yoke.... then all is fine. Means the "motor" also contoll the plane at all time ( whatever AP is ON or not)
We just define a Range ( Trim 0% to Trim 100%) . The Motor/ Output Config do all the work !

All the problems happen if we like to handle the wheel also as a INPUT and OUTPUT parallell.... and really difficult it goes if we like to do this SAME TIME !

Lets bring the Throttle back to Topic....

Show the current (ingame) Throttle Pos with a Motor..... Totaly easy and no problem....
Show the Position while AutoThrotle is ON .... BUT .... Allow to make Inputs, while AT is OFF..... Thats advanced but Possible.
Finally.... Show the Position with Motor while AT ins ON .... AND..... Allow additonal a all time "override" by the user, by move the throttle (whatever motor is currently ON)... thats the Major Problem and the most difficult thing to buld !

****************

As whiteknuckle say....

The most problematic part here is the "double Phase".
For example.....

Lets say the System is currently controlled by the Motor..... Lets say we have just a Value of 0-100 ( Represent the Percent of Trim 0-100%)
We Engage the Autopilot while Trim is at 50%
Now we expect hypothetical the Virtual Trim wheel is turend by the AP to 60% (starting from 50% point)
So our Motor get the Command " Please turn from current (50%) point to target Position (60%)
It starts Moving.....
BUT
When reaching e.g the 52% Position then the INPUT Poti send also a Command ( like we would move the Wheel by hand) and say to the Sim " Hey... i reach the 52% Pos.... Please set the Virtual Trim to 52%!" ..... then we struggle..... We "override" the virtual one like we would do a manual Input.... But we not do this really..... Just the Poti "think" we dop this!

Without a "protection" the INPUT will struggle the Output all the time!

So we need to "disable" the Input, while Motor work ! (Possible by Preconditions)

BUT again.....

What if we like to override the AP really by our itention ( E.g. like in throttle, if we make a TCAS Descent or a rejected TakeOff ??? )
So .... Our system MUST know if the "Input" is done by the Motor (by fault) when it move the Wheel/Throtle .... OR it must also understand if the new Input is directly done by the Pilot !


Thrust me guys..... THIS is the "Most difficult thing" i ever spot in a Homecockpit !

Pretty sure possible with own written Software and specially designed Hardware ( mechanical and electrical) . BUT Verry difficult until impossible with simpel Motors and MF Code !
We can buld it.... But we need to make som e compromises..... a 100% Real Situation i think is still not possible with MF and a < "less" 100$ Hardware !

Hi all,

@pizman: I agree on your explanations.

I have fully redesigned the unit.



The servo-motor unit is now separated from the joystick poti unit. The wheel can mechanically engage either with the motor for autopilot flight or to the joystick potentiometer (= elevator trim input via joystick/Arduino Micro etc. board). This is done with a SG90 servo which is controled by Mobiflight (Offset for AP ON or whatever suits).

The first test with MSFS 2020 was successful.








I have prepared the 3d-files, short instructions and a BoM to be downloaded at my web space:
https://www.vmbollig.de/motorized-elevator-trim-wheel-unit.html

I'm perfectly happy with any question, comment and/or suggestion.

cheers

Volker

Maybe, if i'm not totally wrong with my thoughts, i think i have a solution.....just to stress this issue a little more

Preconditions

* Stepper (M), wheel and two 10-turn potis (P1, P2) are on one axis connected.
(Two potis as - as far as i know - you cannot use the same device, here the poti, for two different conditions / calculations / comparisons....
* Relais depending on AP on or off.
AP = On -> Power to controller board enabled
AP = Off -> Power to controller board disabled
* Stepper not connected to board directly, only the common 5V-line.
* Between the four controlled lines each one 1N4148 inserted to block current flow when turning motor manually to protect controller board
(Test it: turn the stepper and the 4 LEDs on the board will light. But no longer with the diodes....)


Now from my logic:

AP OFF
* Ignore P2
* Turning the wheel manually -> P1-value (converted to FSUIPC-conform value) send to Offset 0BC0 -> FSUIPC sends trim command to plane

AP ON
* Ignore any value of P1
* AP "sends" trim value to 0BC0 and plane will be trimmed
* Comparison between "recalculated" value from 0BC2 (which follows 0BC0) with calulated value of P2 and turning stepper until converted P2-value is equal to 0BC2

As P1 and P2 should always have the same "value" i think there shouldn't be any problem when turning AP on and off and on....

But i don't know yet, how to implement this with MF.

And now: tear my thought into pieces.....

Kai,

that's one interesting approach. Using a stepper instead of a servo motor. This might work. The stepper may be controlled by a separate board (a Nano would be sufficient) and connected to a stepper driver TB6600 (I have them laying around here). This drivers have an enable input to "free" the stepper motors when not driven. Hence, AP engaged: motor enabled, AP disengaged: motor disabled.

As far as I understand, you provide the elevator trim value to Mobiflight directly and not via a separate joystick-board? That might work fine since Mobiflight may ignore the input value when AP is engaged.

Problem here is that Mobiflight to date cannot control two/three wire stepper motor drivers like the TB6600, only those tiny ULN2003 like four wire boards.

To solve this, Mobiflight should either provide a means to control the bigger stepper (TB6600 and the like) drivers or the possibility to communicate to another Arduino directly (likeI2C).

cheers

Volker

In my first tests i connected the "tiny" ULN2003 with the small 28BYJ-48 stepper to MF and it worked fine.
For our needs we do not need a motor being able to lift 20kg, do we?

And then you do not need a seperate Nano.

And the workoaround for the missing "set free" possibility is the relais, cutting the power supply for the board.
Then the (already printed 15cm) mounted wheel can be turned around quite easily. The magnetes and coils in the stepper will generate some current when turned manually, but the mentioned 1N4148s are protecting the board as they block it, as the current-direction is exactly opposite to as when powered the original way. Tested and measured.

In my thoughts it should work when the wheel is turned that the 10-turn-poti thows out a value and with a smartish formula this value could be converted into a FSUIPC-conforn value to control the Flight-Sim.

Now we "only" need the logic for the MF, but i will figure out (at least with the help of pizman).

For our needs we do not need a motor being able to lift 20kg, do we?

The 28BYJ-48 stepper will surely work for the trim wheel. I am certain that your approach will work.
For a throttle lever, this stepper is to weak. I tested this already.

cheers

Volker

Hi Again guys

Just a personal request.....

For my opinion..... a STEPPER will be imposible ! I not can figure out a way a stepper ever can work !
May i´m wrong..... But currently i simply not have a ide how a stepper will work here!

In case we all three speak german.......
I´m out of work from Wednesday for 3 weeks.....
May we find a moment on Discord when we all three are online....
Lets talk about that! ( best way in german, but also possible in english).

Explane me your idea.... lets make maybe a expample Live on Discord to test/confirm!
I´m intersted.... But for the moment i not believe you can do this !

Hi,

I will be available on Discord all day. Please propose a time.

cheers

Volker