MobiFlight Community Support

Hallo,

ich habe mit mit Mobiflight und einem China Arduino ein MCP und EFIS gebaut. Ich habe nun das Problem, dass die Schalterstellungen oft nicht korrekt erkann werden. Im Schnitt bei jedem 5. umlegen der Wippschalter oder Drehschalter erkennt FSX die neue Stellung nicht und verbleibt in der Alten. Sehr ärgerlich, da ich ja an der Hardware die aktuelle Auswahl z.B am EFIS erkennen möchte. Mir ist nach vielen Testdurchgängen aufgefallen, dass das Problem öfter auftritt, wenn die CPU am Maximum arbeitet und dass die Ergebnisse besser werden, wenn das FSUIPC Aktuelisierungsintervall auf Werte >300 ms eingestellt ist.
Was könnte ich gegend das Nicht-Erkennen unternehmen?
Wäre ev. ein regelmäßiges Auslesen der aktuellen Schalterstellung realisierbar? Eventuell mit einer eigenen Device-Kategorie für echte Schalter (keine Taster).

Liebe Grüße

Hallo,

ich hab das selbe Problem, bei Kippschaltern und auch bei Tastern werden Schalterstellungen übersprungen. Ich verwende ein original Arduino Board, an deinem Chinesischen Modell kann es also nicht liegen.

Hatte das selbe Problem aber es war plötzlich weg.....

Auch bei mir machte es den Eindruck, das die Systemauslastung die Fehler negativ beeinflusste und diese sich häuften wenn "viel" los war.

Bei mir hörte es auf mit der neuen Version 6.3 (Die mit der Unterstützung der Event ID´s)

Womöglich könnt ihr das ganze ebenfalls reproduzieren mithilfe eines Regestrierten FSUIPC.....

Öffnet mal die LOG Console und überwacht den Offset den ihr mit besagten Schalter ansteuert.... Mir ist aufgefallen das immer wieder Schaltbefehle gar nicht bei FSUIPC ankamen (bzw dort nicht erkannt wurden).
Interessant war, das dies nur bei Aktiver SIM auftrat. Befand sich der FSX im Ruhemodus (z.b. während FSUIPC geöffnet ist oder im Freiflug Fenster) dann erkannte man im Logfile der Console das JEDER Befehl angenommen wurde.... Sobald der FSX wieder aktiv lief waren wieder Fehler zu sehen.

Ich habe MF 6.3 und FSUIPC registriert. Ich kann #3 zustimmen, wenn FSX im 'Ruhemodus' ist tritt das Problem so gut wie gar nicht auf. Deswegen vermute ich, dass es sich um ein softwareseitiges Problem zwischen Firmware und FSX handelt.
Weitere Beobachtung: Ich habe z.B. Autohrottle per Kippschalter angesteuert und per LED den Status angezeigt. Wenn ich A/T per Schalter ausstellen will geht die LED kurz aus und dann wieder an.

Grüße

Eigentlich müsste es besser werden, wenn das Poll-Interval kleiner gemacht wird also z.B. 100ms.
Du kannst auch die Log-Ausgabe im MobiFlight Connector anmachen, dann sieht man auch welche Events von den Schaltern ankommen. Falls die Schalter-Events alle angezeigt werden, kann man dann die Kommunikation zwischen Arduino und MobiFlight Connector als Fehlerquelle ausschließen.

Meine Vermutung ist aber auch eher, dass FSUIPC nicht mehr schnell genug die Offsets auslesen kann.

Welche Art verwendest Du denn zum Setzen? FSUIPC Offset oder Event ID?

Hallo zusammen,

ich verwende Event ID's. Setzte ich das Poll-Interval auf 100ms runter häufen sich die Fehler.
Folgendes hab ich heute getestet: Key send im Mobiflight ausgewählt und im FSUIPC dann dem empfangenen Key eine Event ID zugeordnet. Damit kam es zu keiner einzigen Fehlübertragung.

Gruß

Fusa

Optimal wäre vermutlich wenn für EventIDs SimConnect statt FSUIPC verwendet würde.

Ich verwende bei den betroffenen Schaltern Offsets. Fürs EFIS gibts m.W. gar keine Alternative dazu.
Ich werde nächste Woche wieder ei bisschen herum probieren, vielleicht hab ich dann auch neue Erkenntnisse.

Grüße

Ist eventuell Debug-Ausgabe eingeschaltet?

Wäre ev. ein regelmäßiges Auslesen der aktuellen Schalterstellung realisierbar? Eventuell mit einer eigenen Device-Kategorie für echte Schalter (keine Taster).

Hi Sebastian.

Im Bezug auf das andere Gespräch zum Thema "Synchronisierung von MF mit dem FSX" wollte ich obige Frage nochmal in den Raum stellen....
http://www.mobiflight.de/forum/message/1537.html

Wenn ich das PMDG Offset Mapping verstehe hat jeder schalter unabhängig der Event ID zusätzlich auch einen Offset für seinen Zustand ! Die Standard FSX geschichten haben diesen ja sowieso.....

Ich denke der fischhons deutet hier das gleiche System an das ich in dem verlinkten thread beschrieben habe.....

Denkst du das wäre möglich oder hast du sowas bereits im Hinterkopf für die zukunft ??

Also sozusagen keine einmalige Synchro wie wir sie angesprochen haben sondern eine umstruckturierung von MF das die Befehle nicht mehr "blind" an den FSX gehen sondern einne Auswertung gemacht wird und nur bei ungleichheit ein schaltbefehl an den FSX geht.

Ich verstehe aktuell noch nicht recht was das Problem ist. Das einzige was man braucht, ist aus meiner Sicht das erneute Senden der Schalterstellungen bei Bedarf. Dass man das braucht kommt eigentlich aus meiner total selten vor, nämlich z.B. dann wenn ich nicht richtig den Flug beendet habe und beim nächsten Mal Cold&Dark starte. Ich bringe einfach mein Overhead in den richtigen Zustand. Muss man eh, weil ich sonst nicht nach Procedure das Flugzeugs starten kann.

Bitte erklärt nochmal in einem eigenen Thread was Eure Problemstellung ist.

Hinweis für eventuellen Workaround:
Aktuell reicht vermutlich das Arduino zu resetten. Man kann dazu einfach den Reset-Pin überbrücken. Schalterstellungen würden dann zumindest bei On-Stellung synchronisiert.

Es gibt aus meiner Sicht auch keinen Grund Taster oder Schalter zu unterscheiden. Dass ein Taster etwas togglen kann (was ich beim Schalter nicht benötige) geht heute schon mit if/Else oder Vorbedingungen. Gerne möchte ich aber eure Ideen hören, warum ihr das nicht so seht.

Hallo Sebastian,

ich versuche mein Problem am Beispiel Autothrottle Kippschalter zu erklären.

Bei Simulatorstart: Schalterstellung AUS - Offset 0810 = 0
Nach Umlegen des Kippschalters ist bei korrekter Funktion: Schalterstellung EIN - Offset 0810 = 1
Nach erneutem Schalten ist: Schalterstellung AUS - Offset 0810 = 0
Nun der Bug: Ich stelle den Schalter um, aber es passiert nichts. Schalterstellung EIN - Offset 0810 = 0
Die Schalterstellung suggeriert mir, das A/T aktiv ist, im FSX ist aber nichts aktiv. Tritt wie gesagt im Schnitt etwa alle 5-10 Schaltvorgänge auf, abhängig von der CPU Last.

Das Ganze tritt auch bei anderen Offsets auf, z.b. beim Umschalten zwischen ADF und VOR. Auch bei der Verwendung von Event IDs bleibt das Problem.
Bei Tastern tritt das Problem seltener auf, aber dort hab ich eine Kontrollanzeige per Led. Falls die LED nicht angeht drück ich halt nochmal.
Ein Reset hat nichts gebracht.

Übrigens: Die Unterscheidung Schalter Taster habe ich ins Feld geführt, weil ich vermute, dass bei einer zyklischen Abfrage des Status aller Devices vom Typ "Button" im z.B. 100 ms Takt die Performance leiden würde.

Grüße

Danke für die Beschreibung.

Ich würde gerne verstehen, warum die Schaltungen unzuverlässig laufen - ich habe dieses Problem bei mir nicht am PC und bei mir ist der Flusi auch unter Last.

Hast Du "Debug-Ausgaben" aktiviert?
Welche Schalter verwendest Du?

Bei mir läuft FSUIPC Poll Intervall mit dem Standard 300ms.

Hi Sebatian.

Ich hoffe ich gehe dir noch nicht auf die Nerven und ich hoffe weiterhin du verstehst meine Kommentare bei dem Thema nicht als böse Kritik !

Ansich würde ich nur gerne auf die Oben und im anderen Thread gestellte "Kernfrage" eine Info von dir bekommen !

Ist die Umstellung bei MF von "Schaltbefehl bei Tastenimput" zu " Schaltbefehl nach Offsetabgleich" machbar oder nicht ?
Und falls ja was hindert dich ? Großer Programmier-Zeitaufwand ? Gefahr von Instabilität durch höhere Rechenarbeit- Auslesemenge ?

Sorry für die plumpe Frage. Aber aus Sicht eines Aussenstehenden sehe ich die zweite Möglichkeit als die Bessere an. Die von dir mal angesprochene "Synchrofunktion" wäre so automatisch integriert. Fehler wie von "fischhons" wären automatisch beseitigt.. Und ein Disconect von MF wäre auch kein Problem mehr da nach Reaktivierung sich das System selbst Synchronisieren würde. Auf den ersten Blick also nur Vorteile !!

In diesen Sinne verzeih mir bitte meine erneute aufdringliche Anfrage.... Ich versuche nur zu verstehen warum du das aktuelle System SO programmiert hast, bzw was du am anderen Prinzip schlecht findest.

Aktuell ist der Ansatz tatsächlich sehr einfach und trotzdem im Detail schon kompliziert.

Ich bin mir sicher, dass der Ansatz von Deiner Idee im Detail kompliziert werden kann und scheue daher aktuell den Aufwand. Sobald ich Zeit habe, durchdenke ich mir den Mechanismus.

Aber:
Vor allem möchte ich erst die Ursache für die verlorenen Events angehen, bevor ich einen Workaround implementiere, der die Auswirkungen vom eigentlich Fehler korrigiert.