MobiFlight Community Support

Hi,
A have a problem with the movement of 28BYJ-48 stepper motors.
During calibration all goes well. But once connected to FS the gauges read correctly with clockwise movement of the needle, but once direction is reversed there is an error where the position shown is higher than the sim is sending.
I think this is backlash from within the stepper motors internal gearbox.
It is a predictable value. This error is first seen when originally setting the zero position. If you use a counter clockwise movement to reach zero and set it will return to the correct zero position.
If you use a clockwise movement to reach zero, once commanded to return it will over read not getting back to zero. On most of the gauges I have made this is in the order of about 11-12 steps.
To counter the initial error, I need to use interpolation to tell the gauge the distance from 0 to the first index position as this is always greater than the subsequent moves.
Obviously if I was to use a better motor then things might possibly improve. I would however like to find a solution for the 28BYJ-48’s as I have a lot of them and would rather not redesign my gauges for new motors. I should note that when the gauge moves clockwise again the correct values are shown.
Given the predictable nature of the error, is it possible to set a pre-condition or use another option to tell the gauges that if a move is less than the current position to add a certain number of steps? I know that would mean messing with the positive values too and then a correction would then need to be applied to the positive moves following negative moves.
I have made seven gauges so far. Most involve some additional gearing – spur gears with a reduction of about 1.3, but one the altimeter is directly connected to the motor output shaft and it too is affected with the error. In that case it shows 12Ft above the FS vale on counter clockwise decreasing values.
I have a video of some of the engine gauges displayed next to a monitor with the FS gauges visible.
You can see a one point (around the 4-minute mark) I rapidly reduce power causing an N2 and rotor RPM (Large gauge) to overspeed. In the sim this is transient, but on the gauge the needles remain above the redline until a larger power change is made. The N1 gauge (with small needle inset) also show the error with decreasing values. One other thing to note that caused me a lot of concerns early on is the Top gauge Torque % visible on screen does not report the actual torque being used. It under reports compared to the FSUIPC value around 2% so this is not related to the other problem.
The other gauges I have completed a a20,000 altimeter, 6000Ft Vertical speed indicator and an airspeed indicator. I am just finishing a Radio altimeter modelled on the KNI416. The error in the VSI is quite annoying as holding a level with reference to this gauge is useless as it can show a slight climb while descending.

https://www.youtube.com/watch?v=yog1Pv6Yd1E



I hope someone can help with these issues.
Thanks. I’m really excited using mobiflight as it’s finally giving me the freedom to build my own instruments, radios, annunciators and more importantly the ability to configure them without any programming knowledge.

Cheers,
Stuart


Just in case anyone is curious I have designed all the gauges in fusion 360 and use hobby gears from AliExpress and Banggood. The shafts are mostly brass tubing with bushings cut from the same material. All the gauge decks, faces, rings and enclosures are 3D printed on a Prusa i3 MK2S. I use 1/16” laser cut acrylic discs from US supplier Delvie’s plastics. The faceplates/scales are designed in Paint Shop pro 2017 and printed on a Brother HL3150CDN colour laser printer. The coloured arcs are then overpainted by hand with acrylic fluorescent paints. I should note that to prevent the arcs being too dark I print the gauges in colour with washed out or significantly paler yellows and greens. The red isn’t a big issue. The yellow arcs I am replicating are not as bright as normal fluorescent yellow on its own, so I paint it first with insignia yellow. The red lines I have had better coverage using an enamel fluorescent red.

Hey Stuart

Great job - really well done.
I know what you are talking about - the stepper unfortunately can be slightly off after changing direction.

I had built a VSI for test purpose and didn’t find it too annoying. We are talking about a couple of feet and not a hundred, right?

Ideas to fix this are appreciated. Not sure of how to build some correction value into the UI. But maybe something like a correction after a direction change to compensate the error. 11-12 steps sounds a lot though. I will check with my stepper again too.

I am very interested in your fusion 360 files. Please share! :-)

Stuart

I afraid the quick answer is no. Try a servo motor instead, they are built to handle backlash.

MF does not have local or global variables, so you cannot track the steady state error in position.

You need SIOC or maybe Air Manager. The latter is instrument based and you can create lua scripts for each instrument. AM drives Arduinos and hence steppers and servos. A lua script could track the hysteresis problems and compensate for backlash.

But time wise a good servo with metal gears might be the quicker solution. They are cheap at HobbyKing.

Good luck
Paul

Hi Sebastian, Doc Mobiuz and Paul,

Thanks for the advice. I have a few options I can try. I really don't want to go back to using servos as I've been using Simkits gauges for about 13 years now but was never really satisfied with the movement of the servo gauges and often they had larger errors than the ones I'm currently having. I did buy some opencockpits boards and played around with SIOC, but unfortunately I don't have the knowledge required to program/ writer code or scripts. I 've also found that the forums are full of people constantly looking for the same information I was but for some reason other than telling people to read the manuals very few people are willing to share their scripts. That has brought me to mobiflight. I can't tell you how great it is to have access to software that simply works, costs nothing and has a lot more functionality then a lot of expensive products.
I do plan to share my designs. I haven't decided how yet be it stl files or access to the original fusion designs. I'm not a fan of just stl sharing as if you need to adjust anything to fit your own setup its quite messy. It is something I really want to do.
I have some preliminary designs of a Garmin GNS 530, 430 PS and an ADF radio head .I have previously designed made a PS engineering audio panel, but I'll need to scale it to fit real world dimensions. The previous radio setup I was using was elite 4000 modules which are 2CM wider than standard radios and a bit too tall for some of them.
So I'll play around and see if I can reduce the error to a more acceptable level in the VSI. The other gauges are well within acceptable limits for me and they only really show up when I intentionally abuse the aircraft to test the gauges. I'm far more gentle normally!

Thanks again,

Stuart

Stuart,

As steppers work well for you another Arduino might become a closed loop controller.

If you can fit an encoder on the output shaft the Arduino could count the angular position. That gives accurate marks for the stepper to interpolate. Hence the backlash can be overcome, typically by recognising a change of direction.
Some astronomy mounts always approach from the same side, so that the gearbox hysteresis never affects the final few steps. That does lead to a forwards-backwards movement which looks quirky, but is the most accurate solution.

Closed loop steppers with integrated encoders and controllers are appearing on eBay. They retrofit open loop steppers on CNCs etc. You would think that could become an open source Arduino project - have a search.

It's a winter project for me, I prefer to be out sailing in the summer!

Good luck
Paul

Hi all.
Thanks again!

Can I start by apologising! The VSI was completely my fault. In the setup of the gauge I had not taken the extra gearing into account for the total steps. That meant it was using less than a third of its available steps.
I figured that out after disassembling the gauge and redesigning it to use a bigger ratio.
I started the new gauge design with the main output shaft having a 56T gear and it was turned with a 9T on the motor shaft giving a reduction of 6.222222222.

That gave a usable step value from -6000Ft to +6000 (13000) of 12000 steps. It was very accurate but there was too much lag.

I then swapped out the 9T for a 12T changing the usable steps to 9000 with a reduction of 4.6666666. It is still very accurate with much less lag.

If I was to do it again I'd change the main output shaft gear down to something like a 30-40T and that would give pretty good results too.

I'm happy with what I have for now.

I will go back and recheck I haven't made the same mistake with any of the other engine gauges. IF I have it's a very easy fix.

I'll post an update after checking the rest.

My simulator is in pieces at the moment as I'm moving it to a different room that can accommodate a 270FOV curved projection system.
Its still winter here in New Zealand so lots of time being spent indoors!

Cheers,

Stuart

Just read this and not understand a part....

Is the issue fixed all time or does it "self repair" when you change direction again ??

Example with easy values:

Startup at Zero : 0 Sim = 0 Gauge
Rightturn to 100: 100 Sim = 100 Gauge
Now problematic Leftturn to 50 : 50 Sim = for example 57 Gauge ( It not turn correct to 50 in that case as you told us.... Maby its 43 I not know if it turn too less or too wide.)

NOW Question:
What happen if you now change sim Value again to SIM 100 Rightturn ? Does the Motor now torn again to correct 100 Position or does the Issue ( 7 in this Example low or high) already exist... so this turn ends at 93/107 ??

****
Other Question: ( Whatever this is not a Fact if problem is only on Left Turns) ..... Do you use correct Step Count ?
I not know why but Default Mobiflight Data in the Stepper Field is 2040 .... But it must be 2048 i think ! Specialy in a altimeter this 8 Steps will create a big problem after 10-20 Full circles !