MobiFlight Community Support

Hallo,

MobiFlight erzeugt zur Ansteuerung von Servos Impulsbreiten von 0,54 – 2,4 ms, zumindest meine Version 9.4.0. Der untere Wert ist für viele RC-Servos ein Problem, da sie bereits bei ca. 0,7 ms gegen den Poti-Anschlag laufen, den Motor blockieren und einen hohen „Ruhe“strom ziehen, der zur Überhitzung und letztlich zur Selbstzerstörung des Servos führt. Servos mit einer höheren Impulsbreiten-Toleranz können zittern oder gar symptomfrei ihren Dienst verrichten.
Da etliche der in meinem A2A-C182-Cockpit eingesetzten Servos das beschriebene Problem zeigen und keine Einstellmöglichkeit für den unteren Servoweg-Einstellwert im MobiFlight-Connector besteht (der obere Wert wird über die %-Angabe bestimmt), habe ich eine Hardware-Lösung gewählt, die die zu kurzen Impulse (bei 0%) auf 0,8 ms verlängert und die geeigneten von 0,8 – 2,4 ms übernimmt.
Das ist relativ einfach und klein mit einem CMOS-Monoflop 4098 und einem Dioden-OR-Gatter aufzubauen.
Eine geeignete Anpassung der „Transform“-Formel hebt den unteren Ausgabewert von 0 auf einen tolerablen Wert an. Bei der „Interpolation“-Eingabe wird diese Anhebung dann entsprechend berücksichtigt.
An sich würde diese letztgenannte Maßnahme zum Schutz zickiger Servos reichen, wird jedoch MobiFlight gestoppt, tritt das Problem wieder auf: Besonders das Graupner-Servo C2081 rennt mit Wucht gegen den Anschlag, zieht 500-600 mA Blockierstrom und ist erst nach Demontage des Getriebes wieder bereit, diesen Ort zu verlassen.
Solange die MobiFlight-Firmware keine Änderung der unteren Impulsbreite zulässt, sehe ich außer der kurz skizzierten Hardware-Lösung keine andere geeignete Schutzmaßnahme.
Vielleicht haben andere Cockpitbauer bessere Ideen.

Gruß
pekair

Hi

Höre von diesen Problem so zum ersten mal. Muss aber auch gestehen das ich der ANTI Servo Fraktion angehöre und nur Stepper verwende.
Die Idee mit Transform war auch bereits unter dem lesen deines Postings mein erster Gedanke....
ABER genau wie du hatte ich bereits 5 sekunden später die Erkentnis das dies nur im RUN Mode hilft und im STOP Mode ja die Firmware alle Servos auf "0" stellt was wieder zum Problem führt.

Die Hardware Lösung ist interessant.... Aber für meinen geschmack der falsche Weg.
Wenn dein Auto aufgrund der Programmierung des Steuergeräts bei unter 30 Kmh ständigt hupt, dann würdest ja auch nicht den Tacho manipulieren damit er im Stand bereits 30 Zeigt oder du würdest auch nicht die Hupe mit einen Relais abschalten, sondern man würde den offensichtlichen Fehler im Steuergerät ändern.

Ich erstelle dafür mal einen Issue auf Github.
Mal sehen was die Diskussion bringt.

EDIT: Link Github : https://github.com/MobiFlight/MobiFlight-Connector/issues/862

Hallo pizman,

die Wurzel des Übels liegt in der Streuungsbreite der verfügbaren Servos, allesamt analog und mit großen Fertigungstoleranzen von 10-20% bei den frequenzbestimmenden Kondensatoren behaftet. An sich sollen sie Impulse von 1 - 2 ms Breite verarbeiten, das ist der "Normalbereich" bei RC-Anwendungen. Wegen der genannten Toleranzen wird ein größeres Intervall gefertigt, das mal bis 0,5 ms reicht, manchmal eben nicht. Ich hatte ursprünglich versucht, an diesen Toleranzen zu schrauben, was wegen der verwendeten SMD-Bauteile und der bisher fehlenden Schaltungsunterlagen vorerst erfolglos blieb.
Ideal wäre eine Einstellmöglichkeit im MobiFlight-Connector für die untere Impulsbreite ...

Gruß
Peter (pekair)

Hallo pizman82,

in Ermangelung einer Alternativen habe ich vorerst für die FUEL-QTY-LR-Gauge eine Impulsanpassungsplatine (min. 0,8 ms) für die zwei 9g-Servos hergestellt und in das Gehäuse (50x50x50mm³) eingebaut. Mit der MobiFlight-Transformation ($*100/(128*65536))+45 und den Settings Min. Wert 45 Max. Wert 145 Max. Rotation 74% (muss noch genauer angepasst werden) gibt es keine Probleme. Weitere 4 Doppelanzeigen werde ich jetzt nachrüsten. Die gefrästen Platinchen passen mit 32x22x6mm³ gerade so eben mit ins Gehäuse.

Dein Vorschlag, Stepper einzusetzen, lässt sich bei den kleinen Doppelanzeigen nicht realisieren - ich habe zumindest keine Bauformen gefunden, die zu zweit ins Gehäuse passen. Altimeter, W-Kompass, Heading werden mit den üblichen 28BYJ-48 Steppern bewegt; da sind die Gehäuse mit 70x70x70 auch groß genug.

Sollte jemand Interesse oder Bedarf an der Impulsanpassung haben, kann ich Schaltung und Layout nachliefern.

Viele Grüße
pekair

... ein nicht unwichtiger Nachtrag:

Eine vorläufige "Reihenuntersuchung" ergab, dass die Billigservos vom Typ SG90 oder baugleich bisher alle (8 Stück) problemlos Impulse von 0,5 - 2,6 ms akzeptiert haben, die teuren von Graupner jedoch nicht. Das wird wohl der Grund dafür sein, dass mein geschildertes "Problem" bisher nicht aufgefallen ist.

Möglicherweise wird der Ersatz der noch verbleibenden Graupnerservos in den Gauges Airspeed, Tacho, Vario … sinnvoll sein.

Gruß
pekair

Hiho

Zur Formel:
Ich kenne jetzt Spontan den Offset bzw Rohwert nicht. Ich vermute dieses 128 * 65536 und geteile liegt an der FSUIPC situation.
Hier kann man natürlich auch etwas einfacher arbeiten.
Meist gibt FSUIPC einen Wert aus der 0-32767 ist ... Wir brauchen aber z.b. beim Heading 0-359 Also muss man das für ein 7Seg Display umrechnen.
Bei einen Motor ist das aber (meistens) völlig unnötig.
Angenommen die Anzeige geht von 0-100 Der Offset geht von 0-32767 . Dann müssen wir das nicht runterechenen. Dem Motor ist es doch egal ob er als Rohwert 0-100 oder eben 0-32767 hat. Er splittet den Rohwert schlicht in eine gewisse Bandbreite von Positionen.


Zum +45
Verstehe da deine Logik nicht.
Wenn du beim Servo Setting "Min 45" "Max 145" dann ist das 1:1 das selbe wie wenn du in der Formel die +45 weglässt und bei den Servo Setting Min 0 Max 100 machst.

Deine intention war doch das der Servo im Falle von Rohwert 0 ( Anzeige ganz Links) eben nicht ganz nach Links dreht sondern ein Stück dovor steht.
Sagst du nun aber das "MIN 45" ist dann wird er bei Rohwert "0" (der jetzt ja durch die Formel 45 ist) ERNEUT ganz nach links drehen denn "45" ist ja jetzt der minimal Wert bei dem der Motor voll an den Anschlag fährt.


Zum Bau/Platzproblem

Ich vermute du baust die einzellnen Elemente abgeschlossen. Bildlich wie Yoghurtbecher die du in die Frontplatte steckst.
Viele Leute bauen z.b. eine C172 als eine Platte. Sprich die "Runden Ränder" sind von vorne aufgesetzt.... Die Anzeigen-Hintergrund Bereiche (Skala) sind auf die Platte geklebt/gedruckt .... LEdeglich in der Mitte der Anzeigen ist ein Loch durch das der Schaft geht. Die ganze Mechanik ist dann "frei" auf der Rückseite.
Sprich man ist nicht an das einzelgehäuse gebunden sondern ein motor kann im zweifel auch mal versetzt 5 cm daneben sein mit nen Zahnrad wenns besser und praktischer zum einbauen ist.
Aber egal.... Das ist ja hier kein Faktor für dich.

Hallo pizman82,

vielen Dank für deine ausführlichen Erklärungen.

Zur 45: Der Grund für die 45 liegt in der Impulsanpassung, die erst ab 0,8 ms Breite Änderungen zulässt. Das meint, dass die von MobiFlight gelieferten Impulse von 0,54 bis 0,79 ignoriert werden, weil die ja das betreffende Servo überfordern. In der Praxis würde das Weglassen des Offsets von +45 dazu führen, dass die FUEL-Anzeige erst bei 10 Litern Tankinhalt zu leben beginnt, von 0 bis 10 Litern rührt sie sich nicht. Das habe ich eben noch einmal ausprobiert. Mit diesem Offset (45 ist noch nicht der endgültige Wert) folgt das Servo dem Tankinhalt von leer bis voll. Im Fuel Manager der A2A-Cessna kann man das komfortabel testen.

Die Formel ist im Preset des FSUIPC-Offsets 0x0B7C (Fuel Left Main Level (%)) vorgegeben. Deinen Vereinfachungsvorschlag werde ich ausprobieren.

Es ist, wie du vermutest: Das Cockpit ist modular aufgebaut und über die Jahre seit FS9 gewachsen. Anfangs unter XP mit IO-Warrior- und Tastatur-Controllern gesteuert, nach Umstieg auf WIN7 funktionierte der Transponder nicht mehr zuverlässig und ich war dankbar - und bin es noch - für die Möglichkeiten, die MobiFlight bietet.
Allein die Force-Feedback-Funktion des Yokes ist aus der Anfangszeit erhalten geblieben und hat noch den alten Controller. Zur Zeit sind drei Megas eingesetzt, die meisten A2A Hürden überwunden. Durch die Modulbauweise kann ich alle Komponenten auch auf dem Labortisch testen. Vor einem Jahr begann ich, die Gauges zu konstruieren, was z.B. beim Attitude-Indicator und beim Turn-Coordinator eine Herausforderung war. Alle Gauge-Teile sind mit FreeCad und 3D-Druck entstanden, so auch deren Schachteln.
Da das Cockpit keine 1:1 Design-Nachbildung sein soll, sondern die Funktionen möglichst vollständig ausführen soll, war die Modularbauweise für mich optimal.

Vielen Dank nochmal für deine Unterstützung

pekair

... die Vereinfachung habe ich probiert:

Die Flight Sim und auch die Output-Werte (FUEL) gehen dabei von 763 bis 8 293 283 ! Wenn ich diese Werte für Min und Max eintrage, rührt sich das Servo gar nicht mehr - warum auch immer.
Mag sein, dass es einen anderen FSUIPC-Offset mit bescheideneren Zahlenwerten gibt, gefunden habe ich auf die Schnelle keinen.

Gruß

pekair

Jepp.

Das liegt drann weil die Servos wenn ich mich recht entsinne mit 16 Bit Signed Arbeiten. (In der MF Logik) Vielleicht waren es auch nur 15 oder 14 Bits.
Heist der Value der angezeigt wird ist 0-16383 oder eben nur 0-8192 oder 0-4096

Wie du sagst.... Meistens sorechen wir ja von Values wie 0-360 0-1000 oder so.

Aber der Grundgedanke ist der selbe.
Wenn 32767 nicht geht und der wert schlicht Linear ist dann reicht auch ein $/10 .... Schon haben wir 0-3277 und sind in der Range.
Aber egal.... War nur ein Gedanke. Natürlich funktioniert auch deine Logik !

I think the problem should not be solved by adjusting the values ;Mobiflight sends. Servo should have limits for PWM upper and lower end that have very conservative settings by default, but you could adjust them high and low end stops in case your own servo can handle values beyond the common RC servo ranges.

So servos would have a range for PWM that is mapped to simulator values, and if the sim variable gets crazy big or negative, the servo would only move and stop at the corresponding and defined end of the range. It might be useful to set the range of your servo high to maximize the movement on certain gauges, but it should default to a very conservative and safe value.

Something like "low end" and "high end" slider might be something where you could move a slider and the servo would move to the given pwm range, until it starts to stutter or hits an end stop, at which point you would back up a bit and set the end stop to a value that is just short of the hardware end limit?

Hi Tigerfly ( i expect i talk to tuomas)

Sorry about german language.
Just to clearify....
The problem is very basic.
For sure we can Limit the Servo Movement by MIN/MAX and RANGE settings or with a formula.....
But the problem requested by the user is more in the deep.....

Mobiflight, or better our Firmware move Servo in STOP Mode to the Zero Position. But as the user said this Position is technical below the left endstop.
So his servo ( when MF is in STOP but the Arduino is powered and Firmware is in "armed" state) always turn against the physical Endstop..... Cause the Zero Position ( based on Firmware) is "below" the physical Zero Endstop.

As i said..... I think to solve this we need a Firmware rework....
Or maybe much more easy.... A Simple relais that "cut" the power of Servo aslong MF is not in RUN Mode !

Guten Morgen pizman82,

die Idee mit dem Relais ist prima, ich werde sie umsetzen.
Aber "Sorry about german language." verstehe ich nicht. Noch nie habe ich gelesen "Sorry about english language."
Übersetzungsprogramme funktionieren in beiden Richtungen, also auch für den Lesenden.
Gruß
pekair

Hi Peter.

Ja... Das "Sorry" hört sich blöd an. Und Ja... Wir beide kommen aus DE... Auch Sebastian ( der Schöpfer von MF) kommt aus DE.
Aber mittlerweile ist unsere Community auf tausende Leute angestiegen und wir Deutschen sind schon lange in der Minderheit.
Deshalb gilt auch bis heute offiziell English UND auch Deutsch als anerkannte Sprache hier auf Mobiflight.com

Ich selber arbeite weiter in dem Gedanken das ich Requests auf Deutsch auch in Deutsch beantworte ( Ist ja eigentlich blöd wenn zwei leute die gleiche Muttersprache haben und dann in einer anderen sprechen) aber fakt ist natürlich das andere Leute die eben nicht Deutsch sprechen dann den Translator brauchen um mitzulesen oder eben auch bei ner Frage ne Antwort geben zu können.

Da faktisch nur 10% Deutsch sprechen und die anderen 90% zig verschiedene Sprachen haben, ABER gleichzeitig fast alle English können hat es sich als "guter Ton" eingebürgert das man soweit irgend möglich (alles was öffentlich ist und nicht PM) in English zu schreiben.
Denn So brauchten nur ein paar Leute die kein English sprechen nen Translator.... Aber 95+% verstehen es ( wenn auch für die meisten nicht die Muttersprache).

Also... Kein Vorwurf... Kein Schelchtes Gewissen. Nur so als Empfehlung.
Gerade auf Discord kriegst mit ner Englishen Anfrage 5 mal mehr Antworten als mit einer Deutschen.
Du wirst auch in der echten Welt keinen Low Aproach in EDDF kriegen wenn du auf Deutsch den Turm anfunkst.... Auf English hast bessere Chancen :-)

Zum Ende ein Funny Fact.... Ich hab hier in MF schon mit leuten 3 Stunden geschrieben (teils sogar telefoniert) auf English und dann haben wir irgendwann mal gemerkt das wir beide aus DE kommen.
Somit: Keine Angst vor English. Kaum einer von uns kann es perfekt. Aber wir alle verstehen uns gegenseitig ohne probleme !

Hallo pizman82,

deine Argumente kann ich nachvollziehen. Ich werde mich bemühen, to do better in the future.

Quote:
„Mobiflight, or better our Firmware move Servo in STOP Mode to the Zero Position. But as the user said this Position is technical below the left endstop.
So his servo ( when MF is in STOP but the Arduino is powered and Firmware is in "armed" state) always turn against the physical Endstop..... Cause the Zero Position ( based on Firmware) is "below" the physical Zero Endstop.“

Why is there a problem, just setting the value of zero-position in MF from 0.54 to 0.7? Sometime Sebastian must have had something like a idea of this value, why did he choose this one and not any other? In other words: Is it really that hard to swap an old value with a new one?

Suppose the case that MF is starting PWM at 0.7 0r 0.8 ms, it will return to this point, if and when MF ends its service and any servo will survive – no problem at all.

Have a nice weekend

Peter

Thanks for reporting this.

I am using the standard Arduino Library for Servos. On their GitHub repository I found an interesting issue:
https://github.com/arduino-libraries/Servo/issues/3

There somebody is pointing out that the timings are not the typical timings used in servos these days.

Interestingly after 6 years, it is still open. the Servo library is one of the few libraries that we haven't forked yet. I will have to do that to make the change until they introduce it into the main library.

Alternatively we could think of upping the lower internal value as I am doing it for the upper limit. Not sure if that is a great solution though.

From a priority point of view: After so many years, you are the first person bringing this problem up. Can you provide us a link of the servo you are using? the SG90 are the ones I was developing with and I didn't experience the issue.