MobiFlight Community Support

Hallo zusammen

Ich bin im Aufbau der A320 FCU mit Arduino Mega, Jeehell und FSX. Ich sitze schon lange auf dem folgenden Problem und komm nicht weiter...

Das Problem: Wenn ich die Encoder (egal ob für ALT, HDG, SPD, QNH) langsam drehe z.B. 1 Rastung pro Sekunde funktioniert alles perfekt auf beide Richtungen. Sobald ich aber schneller als ca 2 Rastungen pro Sekunde drehe, dann können die Werte nicht mehr folgen und die Änderungen werden wie verschluckt.
Der Fast-Modus würde im Prinzip funktionieren (z.Bsp. mit 10er Schritten). Aber auch hier: wenn ich zu schnell drehe, werden auch diese Fast-Änderungen verschluckt und nicht übernommen. Das heisst das funktioniert nur wenn ich eine ganz bestimmte Drehgeschwindigkeit am Encoder erwische.

Eine LED Schaltung funktioniert gut, z.Bsp. der FD Button und die dazugehörende LED. Wobei zwischen dem Drücken des FD Buttons und dem Aufleuchten der LED Leuchte vergeht auch etwa eine knappe halbe Sekunde. Aber das könnte normal sein, ist es das?

Ich habe schon viele Encoder probiert (KY040, Alps, andere), das Problem habe ich mit allen Encoders. Und ich habe auch bei jeder Rastung eine Änderung wie es sein muss (also nicht nur bei jeder 2. oder 4.).
Bei den Einstellungen verwende ich Jeehell Datapipe und die Werte $+1 und $-1 bzw $+10 und $-10. Mit dem Regler für FSUIPC Leseintervall hab ich auch schon erfolglos gespielt.

Von Mobiflight verwende ich die neuste Version und Firmware für den Mega.

Beim QNH könnte ich noch damit leben, aber während dem Vectoring ewig lange zu haben bis das HDG drin ist, ist einfach unbrauchbar und eh unschön.

Hatted Ihr schon mal was Ähnliches?
Könnt Ihr so schnell drehen wie Ihr wollt und die FCU folgt immer?
Gibt es was typisches zeitkritisches bei dem Aufbau mit Encoder was bei mir am Anschlag sein könnte? USB, PC, Firewall?

Vielen Dank für Eure Hilfe!
Dani

Hi Dani,

willkommen bei MobiFlight!

Hast du schon einmal versucht, das Schaltverhalten deiner Encoder zu analysieren?
Probier mal bitte mit 2 LED's, die über je einen Vorwiderstand (470 Ohm bei 5V) an die Ausgangspins des Encoders angeschlossen werden (meist die beiden Äußeren) und lege auf den mittleren Pin des Encoders GND.
Wenn du dann den Encoder langsam drehst, kannst du an den Leuchtdioden sehen, wie der Encoder schaltet.
Was passiert von einer Rastung des Encoders zur anderen (nennt sich Detent). Wie oft leuchtet jede LED dabei auf. Nach wie vielen Detents sind alle LED aus. Also erstmal einen Grundzustand herausfinden. Dann Detent für Detent drehen, bis dieser Grundzustand wieder eintritt.
Wenn dein Encoder z.B. pro Rastung mehr als einen auszuwertenden Impuls ausgibt, kann es sein, daß bei zu schnellem Drehen Impulse verloren gehen.
OK wäre z.B. 1 Impuls (also beide LED einmal an und aus) bei 2 Rastungen. Umgekehrt, also 2 oder mehr Impulse pro Rastung können evtl. nicht erfaßt werden. Dreh den Encoder beim Testen sehr langsam zwischen den Rastungen, weil sich da bereits etwas ereignen kann. Die LEDs gehen nie gemeinsam an oder aus, immer nacheinander. Wenn du den Eindruck hast, sie gehen gemeinsam an, einfach noch langsamer drehen.
Dieser Test dient lediglich der optischen Kontrolle. Der Arduino kann erheblich mehr Impulse pro Sekunde verarbeiten, als das menschliche Auge wahrnehmen kann.

Ich selbst habe Encoder im Einsatz, die 1 Impuls nach 2 Detents abgeben und die kann ich so schnell drehen, wie ich will und der Eindruck ist der, daß offensichtlich nichts verloren geht.

USB und Firewall und auch der PC dürften als Ursache ausscheiden. Bei USB ist die Datenrate zu hoch, die Firewall läßt einen Port durch oder ist gesperrt und scheidet somit auch aus und der PC sollte diese für ihn lächerlich langsamen Signale auch einwandfrei verarbeiten.
Ob und wenn ja eine Software, also MF oder Jeehell, für Datenverluste in Frage kommt, würde ich ebenfalls ausschließen, sonst würden das andere User ebenfalls kritisiert haben, was mir hier im Forum bislang nicht aufgefallen ist.
Bleibt im Grunde nur der Encoder. Hast du die Kabel verlötet oder gesteckt, wie lang sind die Kabel?
Pizman berichtet häufiger von Fehlern bei gesteckten Kabeln oder bei zu langen Drähten, wo dann Daten verloren gehen können. Bei langen Kabeln (>15cm) helfen evtl. abgeschirmte Kabel, bei denen der Schirm dann auf GND gelegt wird.

Berichte mal bitte, welche möglichen Fehlerquellen du bei dir haben könntest und oder der Test etwas hervorgebracht hat.

Hi Dani

Stephan hat den Encoder als Fehlerquelle bereits behandelt ( Da kommt der Elektriker durch )
Ich vermute aber das es eher wo anders liegt, da du bereits meintest du hast "viele Encoder getestet" . Trotzdem ist der Testlauf von Stephan ne gute Sache wenn du mal ein Problem in dieser Richtung hast !

Ebenfalls stimme ich zu, das USB nicht das Problem sein kann.... Auch die Firewall würde ich ausschließen. Ich nutze zwar keine Firewall ( Noch nie benutzt in 30 Jahren) aber du solltest das ja einfach testen können.... Internetkabel weg ... Firewall aus ... testen. Keine Gefahr ohne Internetverbindung ! Aber wie gesagt... Denke das ist es auch nicht.

Kommen wir zu meiner Vermutung:

Stephan meinte das der PC als Fehlerquelle wegfällt. Da stimme ich nicht zu. Ich kann auf meinen System klar belegen das die CPU Leistung sehr wohl drastische Fehler verursachen kann.... Und zwar auf seiten von FSUIPC bzw dem FSX. In meinen Augen ist das auch die Ursache des "Logging Debug" Problems das wir leider bis heute nicht lösen konnten.

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

Falls du Zeit Lust hast kannst du uns hier helfen und mal was testen.....
( Ich verwende leider kein Jeehell und werd es auch nicht nochmal installieren. Sorry dafür)

A) Vorweg teste bitte ob dein Problem gelöst oder schlimmer wird wenn du in den Settings "Logging Mode" aktivierst und zwar auf dem "Debug" Modus. ( Bzw deaktivierst wenn er an ist) Wir haben mehrere Berichte das die Encoder nachhängen wenn dieser verwendet wird.

Weiterhin würde ich dich bitten mal mit der gleichen Hardware einen Test auf einen Standardflugzeug zu machen. .... Steuere mit deinen Encoder mal bitte 2 Funktionen....
1. Eine Funktion mit Event ID.... Z.b. Das Autopilot Altitude der Standard B737 mit den Befehlen Increase / Decrease
( Wenn ich richtig im Kopf habe AP ALT VAR DEC 65893 AP ALT VAR INC 65892)
2. Eine Funktion mit Offset-Manipulation.... Z.b. eines aus den Mobiflight Presets wie Ap Altitude oder AP Heading

Hier geht es darum das Jeehell ziemlich umständlich arbeitet.
Jeehell schreibt den aktuellen Wert auf einen Offset.... Diesen müssen wir mit MF lesen. Dann muss MF diesen Wert umrechenen ($+1 z.b.) und das Ergebnis in die Datapipe schreiben. Jeehell erkennt dann die änderung der Datapipe, liest diese und verarbeitet diese Intern um dann das neue Ergebnis wieder auf den Leseoffset zu schreiben.
Somit ne handvoll Schritte mehr als in einen Standardflugzeug. Dort schreiben wir DIREKT ein Event auf FSUIPC und dieses führt es aus... Fertig !
Ist das System schon an der Grenze dann kann das bereits die Suppe zum überlaufen bringen.

C) Zu letzt kannst du mal noch schauen ob sich die Lage entspannt wenn du deinen System "Arbeit" abnimmst.
Öffne dazu bitte mal nicht das gesammte Jeehell sondern nur die wichtigsten Funktionen ( Sofern du auf einen PC arbeitest ) Wichtig ist also das am FSX PC möglichst wenig Dinge laufen wie die ganzen Jeehell Fenster. Weiterhin verwende bitte den FSX selbst als "Fenstermodus". Jetzt minimiere alles was geht. Vor allem den FSX. Lasse nur das aktiv das du die reaktion des Encoders sehen kannst ( MCP Panel) oder verwende falls bereits verbaut eine Output 7 Segment um zu sehen wie sich z.b. dein Heading ändert.
WENN es an der Systemleistung liegt (wie bei mir) dann sollte das eine spürbare Änderung bringen..... Der FSX braucht deutlich weniger Prozessorleistung wenn er minimiert läuft.
(Bei meinen Problem sind alle Fehler weg sofern ich den FSX nicht mehr als Offenes Fenster verwende )

********

Sorry für den langen Text und sorry das ich dir "Hausaufgaben" gebe.... Aber vielleicht können wir dir besser helfen wenn du das mal machst und uns bescheid gibst was rauskam. Danke für deine Hilfe !

Ich würde gene mal wissen wie Ihr überhaupt an die Offsets für SPD HDG ALT und V/S kommt oder her habt ?
Ich sitze auch an der Umsetzung der FCU vom A320 über Jeehell uznd scheitere an diesem punkt.
LG
Klaus

???
In deinen Jeehell Ordner wo du installiert hast ist ein Manual das alles erklärt bzw eine Offsetliste mit allen Offsets.... Inclusive der von dir genannten !



Oder meinst du was anderes ???

Hallo zusammen
Erstmal vielen Dank für die detaillierte Hilfeleistung & Eure Zeit! Ich teste alles gern ausgiebig wie Ihr vorgeschlagen habt. Als erstes hab ich mir die Schaltung mit den Encoder vorgenommen, damit ich erst mal sicher bin, dass ich doch den korrekten Typ verwende. Nachfolgend findet Ihr meine Auswertung für alle Encoder, die ich zur Hand hatte. Ich war erstaunt, dass einige effektiv unterschiedlich arbeiten. Auf jeden Fall reagiert meine FCU mit all diesen Encodern wie beschrieben sehr langsam. Könntest Du Dir das mal ansehen, ob diese alle OK wären (dann mach ich mich an die anderen Tests) oder ob ich hier effektiv alle getroffen habe, die unbrauchbar sind für diese Anwendung?
Vielen Dank!!
Gruess
Dani

A=LED 1
B=LED 2

ALPS EC11E18244A5
A B Rechtslauf
1 0 1. Rastung
0 0
0 1 2. Rastung
1 1
1 0 3. Rastung

A B Linkslauf
1 0 1. Rastung
1 1
1 0 2. Rastung
0 0
1 0 3. Rastung

ALPS EC12E2424407 & KY-040 & TT electronics AB EN12-HS22AF20
A B Rechtslauf
0 0 1. Rastung
0 1
1 1
1 0
0 0 2. Rastung

A B Linkslauf
0 0 1. Rastung
1 0
1 1
0 1
0 0 2. Rastung

BOURNS PEC11R-4220F-S0012
A B Rechtslauf
0 0 1. Rastung
0 1
1 1 2. Rastung
1 0
0 0 3. Rastung

A B Linkslauf
0 0 1. Rastung
1 0
1 1 2. Rastung
0 1
0 0 3. Rastung

BOURNS PEC11R-4020F-S0024
A B Rechtslauf
0 0
0 1
1 1
1 0
0 0

A B Linkslauf
0 0
1 0
1 1
0 1
0 0

Hi Dani,

brauchbar sind eigentlich alle deine Encoder.
Ein Augenmerk würde ich aber immer auf die Rastungen legen, denn gerade die billigen Encoder haben meist auch eine geringe Lebenserwartung. Es gibt welche, die "leben" laut Datenblatt 10.000 Umdrehungen, andere mindesten 200.000. Wenn du da einen hast mit 10.000, der aber pro Impuls 4 Rastungen hat, dann lebt der halt nicht so lange wie einer der pro Rastung einen Impuls bei 200.000 Umdrehungen hat.

Daher ist eine 1:1 Rastung, also 1 Impuls pro Rastung (wie dein ALPS EC12E..) schon mal gut. 1 Impuls für 2 Rastungen ist auch noch OK, danach artet aber dann das Einstellen auch schon in Arbeit aus.

Wenn denn alle Encoder bei dir langsam oder fehlerhaft ausgewertet werden und du z.B. mit einem 1:1 arbeitest, dann ist die Ursache aller Wahrscheinlichkeit nach nicht der Encoder. Du kannst ja mal im MobiFlight das Debuggen einstellen und beim Drehen des Encoders die durchlaufenden Meldungen bei MF verfolgen. Erstmal langsam drehen und die Meldungen verfolgen und dann schneller. Das Ergebnis ist erstmal egal, nur wichtig, daß die Ereignisse kommen. Es kann sein, daß die Ereignisse etwas nachlaufen, aber sie werden zwischengespeichert und dann angezeigt, bis der Puffer leer ist. Also nicht über einen Nachlauf wundern, gerade wenn du mal schneller gedreht hast.

Dann prüfst du weiter, wie pizman es beschrieben hat. Danach meldest du dich bitte mit den Ergebnissen und dann schauen wir weiter.
Wenn du noch angeben könntest, auf was für einem Rechner, mit welcher CPU/Taktrate (-> Systemmanager), Grafikkarte dein System läuft, könnte man evtl. weitere Rückschlüsse ziehen.

Viel Erfolg!

Hallo zusammen,

danke für die Rückmeldung bzgl. den Encodern! Ich habe die ganzen Tests durgespielt und die Kabel gelötet etc, alles erfolglos. ABER, jetzt denke ich hab ich's gefunden (zwar noch nicht gelöst... ).

Nachdem ich das Problem sogar auf der Standard-B737 nachvollziehen konnte (vielen Dank auch für diesen super Tipp) und ich somit Jeehell ausschliessen konnte. Und ich denke mal auch die Performance Probleme ausschliessen kann mit allem Minimiert und nur das nötigste offen (PC Performance trotzdem noch unten aufgeführt). Wollte ich mich daran machen ein zweites/neues Arduino Board in Betrieb zu nehmen. Das hat noch nicht wirklich geklappt wegen einem Treiber Problem...(und erkennt es irgendwie leider immer noch nicht) aber dabei hab ich gesehen, dass mein aktuelles Arduino Board -trotz physikalischem Anschluss via USB- im Geräte-Manager unter den COM Anschlüssen gelistet ist. Hinter "Arduino Mega 2560" steht "(COM4)". Wenn ich rein gehe und mir die Anschlusseinstellungen ansehe steht da 9600 Bits pro Sekunde Das ist wohl das Problem, oder? passt doch genau zu meinen Indikatoren...langsames drehen --> OK, schnelles drehen nicht mehr. Da ist die serielle Schnittstelle wohl überfordert, oder?

Ich hoffe das war's... also mal happy das (mutmassliche) Problem gefunden zu haben (und dank Euren Test-Tips einiges gelernt zu haben)
... nur weiss ich jetzt noch nicht wirklich wie ich dem PC beibringen soll, dass er eine richtige USB Verbindung zum Arduino herstellen soll anstatt dieser pseudo-seriellen. Ich hab ja einfach die IDE Arduino software installiert... alles weitere hat ja eigentlich automatisch geklappt... aber eben wohl etwas falsch...

Danke Euch
Gruess
Dani

PS, wie gesagt, trotzdem noch die Specs:
PC1 für FSX, FSUIPC, Jeehell (Server), Mobiflight:
i7 3GHz, 6 GB RAM, Win7 64 Bit
NVIDIA GeForce GTX 480

PC2 für Jeehell (Client für FCU, Overhead, ND, PFD, ECAM etc nur für Testzwecke)
i5 2.7 GHz, 8GB RAM, Win 10 Pro 64 Bit
Intel(R) HD Graphics 530

Und hier auch trotzdem noch die Resultate aus dem Debug-Test, falls Ihr ein Nutzen daraus hättet:
Ohne Logging Mode: Problem wie früher beschrieben.
Mit Logging (Debug) Mode: Er verschluckt etwa gleich viel wie vorher. Insofern ist das Problem etwa gleich wie ohne Logging Mode. Der Unterschied ist lediglich, dass mit Logging Mode, die Werte in der FCU noch eine Weile (ca. 2 Sekunden) ändern auch wenn der Encoder schon nicht mehr bewegt wird, wie wenn er die Queue noch abarbeitet. Das passiert ohne Logging Mode nicht. Aber das Resultat ist das selbe.

Hi Dani,

USB steht ja für Universal Serial Bus und die Geräte, die daran angeschlossen werden, erhalten automatisch eine COMmunikations- Bezeichnung.
Wenn du mal die Arduino IDE startest und deinen MEGA anschließt, dann kannst du nachsehen, welcher COM-Schnittstelle der MEGA zugeordnet ist. In deinem Fall dann COM4.
Der Standard auf dieser Schnittstelle ist eine Übertragungsrate von 9600 Baud (Bit per Second). Wenn du so willst ist das die Leerlaufgeschwindigkeit, wie beim Auto, wenn man kein Gas gibt.
Du kannst aber davon ausgehen, daß die Geschwindigkeit für diese Schnittstelle programmierbar ist und ich gehe davon aus, daß Sebastian für die Übertragung einen anderen Wert als 9600 BpS gewählt hat. USB 2.0 selbst hat laut Spezifikation eine Datenübertragungsrate von 480 MBit/s, USB 3.1 gar eine von 10 GBit/s.
Wie sonst könnte man sonst auf einen USB-Stick z.B. 25 MBit/S an Daten übertragen oder HD-Videos streamen? Mit 9600 BpS undenkbar!

Normalerweise sollten deine beiden Rechner auch leistungsfähig genug sein. Vom Grundsatz her. Nun kann ich aber nicht sagen, was z.B. auf deinen Rechnern an Diensten etc. läuft, die ggf, Performance "fressen". Du kannst ja mal in den Task-Manager schauen, wieviel Prozessorleistung benötigt wird, wenn du deine Standard-Sim-Konfiguration laufen läßt. Da siehst du dann unten links CPU-Auslastung ...%. Je dichter dieser Wert an 100% liegt, um so ausgelasteter ist dein System. Evtl. müßte mann dann bei den Prozessen, die beim Systemstart hochfahren und bei den (nicht unbedingt benötigten) Diensten ansetzen und "aufräumen. Einfach mal unten links auf Start klicken und MSCONFIG eingeben. Return und schon kannst du schauen, wer an deiner Rechnerleistung knabbert.

Wenn so erstmal nichts ersichtlich ist, den Rechner mal vom Internet trennen, Firewall ausschalten und alles, was nicht unbedingt erforderlich erscheint, ausschalten (Haken wegnehmen), den Rechner neu starten und schauen, ob sich das Encoderverhalten geändert hat. Wenn ja, dann die Dienste einzeln wieder zuschalten, bis die Impulse wieder verschluckt werden. Wenn du Pech hast, liegt die Ursache noch tiefer, aber so würde ich erstmal drangehen..

Berichte mal, wie's ausgegangen ist.

Jepp.

Das mit den Com sollte so richtig sein. Welche Datenrate Sebastian nutzt weis ich nicht, aber es sollte eigentlich passen.
Über MBits brauchen wir denke ich nicht diskutieren, da man ja immer sehen muss das vom Arduino ansich fast nichts kommt.... Ein drehen des Encoders sendet je nach umsetzung nur einen Bit bzw einen String an den PC.... Das sollte auch bei niedrigsten Datenraten "vermutlich" kein Problem sein.

Zum PC.

Ich bin in Sachen Hardware wirklich keine Leuchte ( Vermutlich habe ich deshalb auch das Debug Problem).
Ich kdenke man kann aber eins Pauschal sagen.... Das Problem des ganzen ist die Strucktur des FSX ( Der ja mittlerweile über 10 jahre alt ist) .
Der FSX kann nicht auf mehrere Prozessorkerne zugreifen... und der FSX kann nur eine begrenzte RAM Menge verwalten ( Glaube 2,x gb) und er ist auf 32bit gecoded.

Folge:
Rein Theoretisch ist ein Highend SINGLE CORE Prozesoor aus dem Jahre 2008 deutlich besser für den FSX als ein aktueller Quad- oder Oktacoreprozessor.... Die neuen sind zwar insgesammt um Welten schneller.... Aber ist es auch ein einzellner Kern ?
Auch das Betriebssystem spielt eine Rolle.... FSX war für XP ausgelegt ( Oder Vista ) aber nicht für Win7/10 . Diese Systeme denke ich brauchen wesentlich mehr Systemleistung im Hintergrund und schmälern die Marge für den FSX auf Kern 1.
Selbes gilt für den RAM.... 32Gb Normaler RAM sind zwar ein vielfaches des damaligen..... Aber rein logisch würden dem FSX 3GB reichen..... ABER die sollten Ultra Schnell sein... Besonders neue PC´s haben zwar viel Ram aber eben billigen langsamen Ram.
Letzter Punkt die Festplatte.... Wir brauchen keine 2 Terabyte... Aber wir bräcuhten ein paar Hun dert Gigabyte die EXTREM Schnell sind... SSD ?

Nochmal: Ich bin da kein Profi.... Aber mir wurde mal in diversen Foren erklärt das selbst ein 8000 € High End Gaming PC von 2017 für den FSX Schrott ist.... DAFÜR brauchen wir ein ganz speziell abgestimmtes System das stellenweise aus heutiger sicht total veraltet ist.... Aber eben genau für den Flugsimulator stimmig ist.

Somit: Ich hab zu wenig Erfahrung damit... Aber Pauschal sein System als "gut" zu bezeichnen ist nicht möglich. Mein PC ( Quadcore 3,3 ghz) erreicht beim FSX selbst im Minimalen Aufbau stets 100% Auslastung auf Kern1

Hi,

also ich habe einen 8-Core-Prozessor mit 3,4 GHz. Als ich den FSX installiert hatte, liefen diese 8 Cores alle an der Grenze und der PC holperte ohne Ende, stürzte ab und ich war drauf und dran, alles in die Tonne zu treten. Da ich aber zu solchen Schnellschüssen aus der Hüfte nicht neige, habe ich mal wieder Tante Google gefragt.
Dabei kam singemäß heraus, eigentlich auch logisch, daß der FSX mit den Multicore-Prozessoren Probleme hat. Auch Speicher mit mehr als 4 GB sind bei einem 32Bit-System problematisch. Nun ist es aber möglich, die Anzahl der Cores, mit denen der FSX arbeiten soll, zu reduzieren.

Die Antwort war sehr umfangreich, aber einen Hinweis bekam ich hier:

https://flightx.net/index.php?thread/31086-tutorial-affinitymask-jobscheduler-f%C3%BCr-multicore-cpus-mit-beispielen/

Baut man in die FSX.cfg

[JOBSCHEDULER]
AffinityMask=56

ein, geht es wesentlich geruhsamer zu. Zum Verständnis sollte man den o.a. Thread mal lesen. Bei mir hat es dazu geführt, daß die CPU-Auslastung drastisch zurückgegangen ist und im normalen Flug kaum mal die 20% überschreitet. Lediglich bei komplexen Scenerien (auch die Komplexität der Darstellung kann man reduzieren) steigt die Leistung in die Nähe der 90%. Das zwischenzeitliche Straucheln habe ich so abgestellt, ebenso unkontrollierte Abstürze (des Rechners - nicht des Fliegers ) gehören bei mir der Vergangenheit an.

Wie denn die AffinityMask eingestellt wird, liest man in dem Thread. Dort wird auch erklärt, wie man die unterschiedlichen Werte für Multicore-Prozessoren und für AMD und Intel-Prozessoren einstellt. Sehr empfehlenswert.

Wer weiter optimieren möchte, kann es auch mal mit FlusiFix probieren.