MobiFlight Community Support

Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.

You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks! 

05/03/2024 - This forum is read-only

The community support for MobiFlight has moved exclusively over to our Discord server. Register for free and enjoy more interactive functions like image and video upload, voice chat. More than 7,000 registered users around the world make it a great experience!

See you on our MobiFlight Community Discord server.

A HUGE Thank You to everyone who participated in the forum, especially obviously to Pizman and Stephan who did an outstanding job over so many years providing an incredible service to the MobiFlight community.

The forum is still providing a lot of good content, hence we keep this information accessible.

Go to page 1Go to page 21234Go to page 4Go to page 4
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Habe grade einen Testlauf gemacht mit einen Default Flieger (Cessna) und das ganze ohne 3110/3114 ausporbiert.

Meine weitere Vermutung zur Read Logik könnte stimmen....

In FSUIPC wird bei aktiven Output jeder Input dauerhaft ausgelesen sobald man ihn einmal verwendet hat....

In meinen Testaufbau hatte ich 2 Inputs und einen Output.

Laut FSUIPC Logging wird der Output Offset ab Aktivierung des MF Conectors dauerhaft ausgelesen. (So sollte es ja auch sein)
Sobald man einen Input Schalter betätigt wird dieser Offset im Anschluss ebenfalls dauerhaft ausgelesen.
Betätigt man den 2. Schalter dann wird nun auch dieser Offset dauerhaft ausgelesen. Also Unter "Read" sieht man jetzt die 2 Schalter Offsets und den Output Offset in Dauerschleife !
Hat man KEINEN Output in MF dann gibt es auch keine Dauerschleife und die Reads kommen anders (siehe nächster Absatz)

****

Bei der PMDG dachte ich erst das wie im letzten Posting geschrieben jeder Schaltbefehl eines Inputs auch einen READ des selben Offsets auslöst. Im Defaultflieger der mehrere offsets und nicht nur 3110/3114 verwendet sieht man aber das die Programmlogik hier viel tiefer geht. Der "Read" betrifft offenbar nicht den Offset des Schalters selbst....


Wenn ich 3 Schalter configuriert habe (Keinen Output) und starte den MF Conector .....
Drücke ich nur mehrmals Schalter 1 loggt FSUIPC nur Write Befehle. Keinen Read.
Drücke ich im Anschluss Schalter 2 dann wird auf diesen Offset ein Write gemacht , aber gleichzeitig ein Read des ERSTEN Schalters.
Drücke ich nun wieder Schalter 1 wird dieser per Write geschrieben , aber gleichzeitig wieder der andere 2. Schalter per Read ausgelesen....

Richtig Chaotisch wird es wenn ich einen Dritten Schalter einmalig drücke.....
Jetzt Schreibt der 1. Schalter seinen Offset und liest Schalter 2 und 3
Der 2. Schalter Schreibt seinen Offset und liest Schalter 1 und 3
Der 3. Schalter liest jetzt erst ALLE 3 Offsets, Schreibt dann auf seinen Offset und liest dann wieder die offsets von Schalter 1 und 2.


*************
Ich vermute es ist gewollt das der Value eines Input Schalters für MF bekannt sein muss damit eine Formel im Value Feld angewendet werden kann mit $Wert.
Allerdings ist die Abfragelogik entweder Fehlerhaft oder ungünstig gewählt (vermute ich mal)

Falls nun FSUIPC ein Problem hat wenn "gleichzeitig" ein Read und ein Write auf den gleichen Offset kommt dann wäre das die Erklärung! Denn diese Situation kommt zufällig immer wieder mal vor wenn ich genau dann den Schalter drücke wärend die Endlosschleife gerade den selben Offset liest !


EDIT: Auf deine Frage... Die Schalter gehen sporadisch verloren. Auch bei betätigung alle 10 sekunden kann ein fehler dabei sein
Good Luck !
2016-01-20 02:34
Avatar
DocMoebiuz
Moderator
From: NW of KPWK, United States
Posts: 1516
Ich hab heute versucht, das Problem nachzustellen:

Ich hab das Parking Brake Setup gemacht.
Schalter steuert Parkingbrake in drei Varianten:
* Via FSUIPC Offset 0x0BC8, setze Offset 32767 (OnPress) 0 (OnRelease)
* Via FSUIPC Offset 0x0BC8 aber mit Logik (OnPress) if($=0,32767,0), damit das Offset ausgewertet wird, also Teil der Logik ist
* Via EventID

Der Status der Parkingbrake wird mit einem LED angezeigt.
In allen drei Fällen war das setzen und lösen der Parking Brake immer erfolgreich und der Status der LED hat immer gestimmt.

Ich verwende schon seit langem ein Radio Panel mit Drehencodern, Switches und 7-Segment-Anzeigen ohne das Events verloren gehen.

Bitte stellt wirklich sicher, dass ihr kein elektrisches Problem habt.
Schickt mir bitte die Configs von dem minimalen Testfall, der bei Euch das Problem zuverlässig nachstellt.
Alternativ müssen wir eine Teamviewer Session veranstalten.
Have a great day!
Sebastian

MobiFlight - Simply build your own home cockpit for your favorite flight sim - MSFS2020, FSX, Prepar3D (FSUIPC), X-Plane (XPUIPC)
2016-01-20 22:34
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Hiho.
Habe um äußere Faktoren auszuschließen eine Systemreinigung vorgenommen. (War nach 3 Jahren eh mal richtig nötig. Also ein komplettes Format und Neuinstallation von Windows und dem FSX)
Problem besteht immer noch.
Dein Ansatz mit der Parkingbrake ist aber vielleicht der Richtige Weg um eine gleiche Ausgangssituation zu schaffen.


Selbst bei dieser Minimalconfiguration kann ich die "Fehler" Nachstellen !
Zum Aufbau (Um elektrische und config Fehler auszuschließen) ....

Kreis 1: Arduino Grd ---> 220 Ohm Wiederstand --> Kathode LED .... Anode LED ---> Arduino Pin
Kreis 2: Arduino Grd ---> Kurzhubtaster Linker Teil ..... Kurzhubtaster Rechter Teil ---> Arduino Pin ( Hab 2 verschiedene Groundpins genommen obwohls ja egal wäre)

Config:
Input: Parking Brake : Offset 0BC8 On press 32767 On Release 0
Output Parking Brake Preset... Offset 0BC8 VB. (Preset) Wenn 32767 Dann 1 sonst 0

**************
Bei Deaktivierten Output : 50 Schaltungen --- 0 Fehler
Bei Aktivierten Output (egal ob LED an/ aus) : 50 Schaltungen ca 8-12 Fehler
*************

Kann übrigens auch das beschriebene Verhalten der LED jetzt bestätigen.... (Bisher hatten meine LEDs ja andere Offsets und nicht den geschalteten)

Kommt es zu einen Fehler zeigt die LED eine Reaktion.
Z.b. Wenn ein Release Fehler auftritt :
Schalter Gedrückt, LED an, Parkingbrake An -----> Schalter wird losgelassen... LED geht Kurz aus, sofort wieder an.... Brake bleibt an im FSX.

Geht auch andersrum bei Push Fehler.....
Schalter Nicht gedrückt, LED aus, Bremse Aus -----> Schalter wird gedrückt und gehalten.... LED geht Kurz an und gleich wieder aus.... Bremse wird nicht aktiviert
Also offenbar wird der Offset für eine Millisekunde geändert was das Blinken der LED bewirkt, aber er springt zurück.
Auch im MF Conector sieht man kurz die richtigen Werte im Output Fenster bei den 2 Spalten aufblinken.

********

Fazit:

Ich kann leider mit meinen beschränkten Programmkenntnissen keine große aussage treffen.... Aber grob gesehen ist der einzige Unterschied zwischen "Mit und Ohne Output" , das der zu schreibende Offset einmal Dauerhaft gelsen wird und einmal eben nicht.

Ein Ansatz um das zu testen wäre eine "Beta" version von Mobiflight die du Mir/Uns zukommen lässt in der du temporär die Logik rausnimmst das Input Offsets gelesen werden.
Bei der Parking Brake geht das zwar speziell nicht da hier der Input gleichzeitig der Output Offset ist..... Aber ich könnte so z.b. mit der LED das Statuslicht von COM1 auslesen und gleichzeitig mit dem Schalter die ParkingBrake bedienen. Folgerlich würde der Offset der Bremse Nicht mehr gelesen werden.
Das ist zwar sicherlich keine Lösung da so keine Bedingungen mehr möglich sind... Aber man könnte vielleicht den Fehler eingrenzen !

Was ich aber nicht verstehe.... Warum sind die Fehler bei dir nicht ??? Hast du die Schaltungen auch auf einen längeren Zeitraum probiert ?? Habe durchaus auch 20-30 Vorgänge am Stück die klappen, aber dann auch mal wieder 4 Fehler innerhalb von 10 Schaltungen.

An dieser Stelle aber nochmal Danke das du dich darum kümemrst obwohl es offenbar nicht jeden betrifft !
[Last edited by pizman82, 2016-01-22 08:24]
Good Luck !
2016-01-22 08:16
Avatar
DocMoebiuz
Moderator
From: NW of KPWK, United States
Posts: 1516
@pizman: Probier doch bitte mal das setzen via Event ID

Noch eine Frage: Du verwendest einen Taster, also solange du drückst soll einmalig der Event "Parking Brake On" ausgelöst werden, sobald Du loslässt einmalig "Parking Brake Off".

Kannst Du mir bitte Deine Mobiflight Connector Config und die Board Config (kann man bei den Settings abspeichern) zukommen lassen. Eventuell kann ich es dann bei mir reproduzieren.
Have a great day!
Sebastian

MobiFlight - Simply build your own home cockpit for your favorite flight sim - MSFS2020, FSX, Prepar3D (FSUIPC), X-Plane (XPUIPC)
2016-01-22 14:24
Avatar
DocMoebiuz
Moderator
From: NW of KPWK, United States
Posts: 1516
Ich glaube ich habe die Ursache für das Problem verstanden und eventuell auch schon behoben.

Bitte nehmt den offiziellen Download Link und erhöht die Versionsnummer auf 7.0.6-beta
[Last edited by DocMoebiuz, 2016-01-22 15:02]
Have a great day!
Sebastian

MobiFlight - Simply build your own home cockpit for your favorite flight sim - MSFS2020, FSX, Prepar3D (FSUIPC), X-Plane (XPUIPC)
2016-01-22 14:56
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Leider noch nicht die Lösung :huh: Hoffe ich versaue dir dadurch nicht die Wochenendstimmung
Habe die Version getestet. Gleiche Symptome.

Zu deinen vorherigen Fragen....
1. Habe einen Taster verwendet da meine Kippschalter Lötösen haben und nicht ins Breadboard passen. Wollte nicht löten. Natürlich verwende ich den Taster mit zeitlich langer Drückphase um einen Kippschalter zu simmulieren. Das meine Schaltungen zu kurz sind und das Polling die Probleme verursacht schließe ich eigentlich aus..... Verwende den gleichen Aufbau auch für die anderen Testläufe z.b. Ohne Output und dort klappte es ja mit dem Gleichen Drück-Loslass Rythmus.

2. Bitte sag mir welche EventID ich testen soll und mit welchen Flugzeug (Standard oder PMDG)

3. Kann dir bei Bedarf die Config und Boardbelegung schicken..... Habe aber Ansich nur die Presets wie oben beschrieben verwendet. Die Pinbelegung ist 52 LED und 43 Schalter.

***********
Aktuelle Beobachtungen:

1 Im FSUIPC Logging wird bei einen "verschluckten" Befehlen wie auch bei der alten Version eine Meldung ausgegeben. Zum einen habe ich keinen notierten Write im Logging wenn ein Fehler passiert..... Auch der nächste Write fehlt natürlich, da der Schalter ja wegen dem Fehler in der Stellung ist die ich mit dem nächsten Betätigen des Tasters Schalten würde..... Kommt nun die Aktion die vorher verschluckt wurde steht im Logging " Write Repeated 1 time". In einigen Fällen wurde auch der 2. Schaltbefehl nicht angenommen.... Beim 3. Versuch kommt dann logischerweise "Write Repeated 2 times".

2. Was ich mir leider gar nicht erklären kann aber vielleicht die "zündende" Idee für dich sein könnte.....
Die Fehler kommen vor wenn MFC Logging AUS ist.
Mache ich das Logging in MF an (Auf DEBUG) dann habe ich keine Fehler mehr !
Ist das Logging aber auf Error oder Warning dann sind die Fehler wieder da.

Womöglich kannst du ja definieren was MF im "Logging Debug" Modus anders macht.

*********
Und noch etwas. Hab heute mit einen Forum-Bekannten über dieses Thema gesprochen. Dieser Programmiert sein HC selbst (ist Hobby Programmierer)
Er meinte auf meine Frage ob ein gleichzeitiges Read und Write ein Problem verursachen kann folgendes.....

iconQuote:

Das sollte kein Problem sein, FSUIPC-Seitig ist da eine gute Fehlerkontrolle was gleichzeitiges Lesen/Schreiben angeht. Das mache ich bei meinem 777 MCP auch so, ein -freier- Offset wird auch bei mir gleichzeitig gelesen und geschrieben, um Verzögerungen zu minimieren.Dazu sind im Quellcode bestimmte Angaben nötig, um Fehlermeldungen zu vermeiden wenn sich die Schreib- und Leseroutinen treffen. Dann hat der Prozess vorrang, der zuerst am Offset anfragt, der andere ist solange gesperrt und tut das auch per Fehlermeldung kund. Der einfache Weg ist eine Fehlerabfangroutine, die das abwürgt. So fällt also immer mal eine Abfrage oder ein Schreiben aus. Der bessere Weg ist, entsprechende Rechte zum gleichzeitigen Lesen/Schreiben zu programmieren. Wie das im MB-Quellcode ist weiss ich nicht.
Evtl. läuft das auch über separate Tasks, so das Lesen/Schreiben synchronisiert sind.



Keine Ahnung ob du damit was anfangen kannst aber ich dachte ich schreib dir das mal !

In diesen Sinne... Schönes Wochenende. Und äregere dich nicht sondern genies deine freie Zeit. Das Problem kann auch noch warten ! lg
Good Luck !
2016-01-23 00:45
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Und noch ein Zusatz.... Hab noch etwas probiert....

Habe Testweise den FSUIPC Intervall mal auf 500ms gestellt und da ist mir was aufgefallen.....

Die Fehler passieren immer noch (Häufigkeit kann ich schlecht sagen... hab nur 2-3 Minuten getestet).... ABER.
Bei 500ms ist das Blinken der LED bzw die anzeige des Richtigen Value im Conector spürbar länger wenn der Fehler auftritt.

Ich hätte eine Vermutung aber kann ohne deinen Quellcode zu kennen und ohne richtige Programmierkentnisse natürlich nur im dunkeln stochern.....

Kann es sein das du für den Offsetwert ansich nur EINE Variable verwendest....
Bei einen Read in FSUIPC wird die ankommende Information von MF auf diese Variable geschrieben. Gleichzeitig dient diese Variable aber auch als Plattform für eine Schaltereingabe..... Also Wenn ich einen Schalter bewege liest MF dies vom Arduino aus und schreibt den neuen Wert auf eben DIESE gleiche Variable.
Dies deckt sich mit der Beobachtung, das der Schaltbefehl offenbar im conector ankommt und umgesetzt wird.... ABER beim nächsten Polling wieder Zurückgenommen wird.
Zu erkennen a. An der LED bzw dem Wert im Connector.... und b. am Fehlen des Logging Eintrags im FSUIPC Logging.

Einfach gesagt sieht es von außen so aus, als würde Mobiflight den Schaltvorgang erkennen..... Den Zustand auf die vorgesehene Variable schreiben.... Aber bevor es diese als Write zu FSUIPC senden kann wird die gleiche Variable von einen Read neu beschrieben und hat wieder den ursprünglichen Wert..

Bin natürlich sehr an einer Lösung interessiert und biete mich weiterhin als "Laborratte" an. Muss zwar am Wochenende immer arbeiten aber kann gerne Nachts Testläufe für dich machen. Bitte nur Detailiert sagen was ich probieren soll und falls erforderlich die neue Testversion per Mail oder Link an mich !

lg .
Good Luck !
2016-01-23 09:04
Avatar
DocMoebiuz
Moderator
From: NW of KPWK, United States
Posts: 1516
Probier bitte mal 7.0.6-beta1

Fakt ist: Ich verwende die lib, die mit FSUIPC mitkommt zum Lesen und Schreiben der Offsets. Mobiflight registriert alle Offsets liest sie und schreibt sie mit Hilfe dieser Library. Wenn die Maßnahmen aus den beiden Versionen jetzt nicht helfen, komme ich nicht drum rum, mir die Implementierung der Library näher anzuschauen. Vermutlich liegt dann der Fehler da.
Have a great day!
Sebastian

MobiFlight - Simply build your own home cockpit for your favorite flight sim - MSFS2020, FSX, Prepar3D (FSUIPC), X-Plane (XPUIPC)
2016-01-23 10:29
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Leider auch nicht.

Testaufbau wie gehabt mit Parking Brake als in und Output....
Fehler im Normalen Modus...... Keine Fehler im "Logging Debug"

Was womöglich auch noch eine Info ist (Wurde von den anderen und mir Anfangs mal erwähnt aber irgendwie nicht vertieft....).....
Wenn ich im FSX auf das FSUIPC Panel wechsle (Also der FSX sozusagen angehalten wird aber ja noch im Backround Befehle annimmt) dann funktioniert Mobiflight Einwandfrei....
Also auch OHNE "Debug Mode" Arbeitet die LED und der Schalter perfekt. Das Logging läuft ja immer noch und ich sehe dort das keine "Write Repeated" kommen und auch die LED blinkt nicht sondern tut was sie soll !

Womöglich liegt es ja doch am "PC" selbst das die Rechneleistung für FSUIPC nicht mehr reicht und bei einen "Dauerread" soviele Arbeitsschritte stattfinden, das er nicht mehr mitkommt.
Laut Resourcenmonitor laufen bei mir 3 Kerne auf minimallast und 1 Kern läuft auf 100% wenn der FSX Aktiv ist. Gehe ich wie oben beschireben auf den FSUIPC Tab dann sinkt die Prozessorlast auf diesen Kern auf fast 0%..... Ich nehme mal an FSUIPC läuft wie der FSX auf diesen Kern 1 !


System: Intel Core i5 2500 @ 3.30 GHz 3.60 GHz RAM: 8Gb Win 7 64 bit Graka Nvidia GTX 570

Kann Fischons, Fusa oder Du vielleicht das mal "prüfen" wie es mit der Prozessorlast aussieht ?
Good Luck !
2016-01-23 11:30
Avatar
fusa
From: EDDF
Posts: 57
Supporter
Hallo zusammen,

die Fehler sind mit der Beta 1 noch da.
Getestet mit der default 737 800 Offset für Parking Brake und der PMDG mit Event ID 70012 für AT Arm SW (Input) und 0x653A für AT Led (Output).
Wie pizman82 schon schrieb, sobald ich das Logging mit Debug Mode aktiviere kommen keine Fehlübertragungen mehr.

Die CPU Auslastung während den Übertragungen:
default Flieger: ca. 15-18%
PMDG 737-800: 30-60%
dabei ist bei mir auch ein Kern fast durchgehend 100% ausgelastet.
Und hier noch meine Systemspezifikationen.

System: i7 4770k @ 4,5 Ghz (OC), RAM: 16Gb, Win 7 64 Bit, Graka Nvidia GTX 970 4Gb Ram.
2016-01-23 12:29
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
OK. Ich nehme an dann können wir das System ausschließen. (Vermutlich)
Hab schon überlegt mir einen neunen PC zu holen.
Aber wenn du in allen Hardwareteilen um Welten besser bist wie mein PC und trotzdem das gleiche Problem hast liegt es wohl nicht primär daran.
Ich verwende nur eine normale HD und keine SSD aber das sollte ja auch nicht so gravierend sein !

@ Sebastian.

Da du dich noch nicht zum "Debug Mode" von MF geäußert hast wollte ich an dieser Stelle nochmal ansetzen.....

Offenbar kann auch "Fusa" bestätigen das im Debug Mode alles klappt.
Anstatt jetzt die Welt neu zu erfinden stellt sich die einfache Frage....
Habe ich denn im Debug Logging Mode von Mobiflight irgendwelche Nachteile?
Falls Nein könntest du sofort mit der Problemsuche aufhören. Falls ja wäre es interessant welche Nachteile und ob man diese akzeptieren könnte als User.

lg
Good Luck !
2016-01-23 13:21
Avatar
DocMoebiuz
Moderator
From: NW of KPWK, United States
Posts: 1516
Debugging veursacht immer ein bisschen Overhead, weil ja Textausgaben erzeugt und in der Programmoberfläche angezeigt werden.
Abgesehen davon gibt es keine Nachteile.

Für mich ist das halt nicht die Lösung fürs Problem und ich würde lieber die Ursache noch beheben.
Have a great day!
Sebastian

MobiFlight - Simply build your own home cockpit for your favorite flight sim - MSFS2020, FSX, Prepar3D (FSUIPC), X-Plane (XPUIPC)
2016-01-23 15:59
Avatar
pizman82
From: ETSI, Germany
Posts: 6010
Supporter
Misst jetzt ist mir ein Posting verloren gegangen..... :scared:

In kurzen Worten nochmal.....

Das Debug Phönomen könnte durchaus auf ein Write/read Problem hindeuten da die Textausgabe ja einen Arbeitsschritt im programm darstellt. Während dieser ausgeführt wird kann er keinen Read auswerten..... Vielleicht Unabsichtlich die Lösung für das Problem ! (Sofern im Debug der einzige Unterschied NUR diese Texte sind)

Warum es nur bei wenigen Leuten auftritt und warum es im "Ruhemodus" geht ist mir weiterhin Schleierhaft !

****

Die FSUIPCclient.xml habe ich mal kurz überflogen..... Ist vermutlich die von dir erwähnte Lib die du verwendest. Interessant sind die "Write Only" Parameter !

Weiß nicht ob diese bereits in MF integriert sind oder in den Betas die du uns gegeben hast..... Ich würde aber falls es dir Möglich wäre gerne noch einen Versuch machen indem der INPUT Offset NICHT gelesen wird.(Oder zumindest nicht mehr per Endlosschleife sondern nur noch per Schalterbewegung) Wie du an die Werte für Vorbedingunen kommst ist erstmal zweitrangig. Interessant wäre es nur, ob dies den Fehler behebt.
Falls sowas mit "wenig" aufwand für dich möglich ist sende mir bitte so ein Testfile zu.


Abschließend möchte ich es dir hoch anrechen was du gerade machst.... Einen Fehler zu suchen den man selber nicht wahrnehmen kann ist die Hölle.... Noch schlimmer das du unsere Testläufe auch nur schriftlich mirbekommst. Denke wenn du an meinen PC sitzen würdest wäre das ganze in 20 Minuten erledigt !
DANKE !!
Good Luck !
2016-01-24 01:01
Avatar
fusa
From: EDDF
Posts: 57
Supporter
hab gerade noch ein Test gemacht um sicher zu gehen, dass es mit aktiviertem Debug-Log zu keiner Fehlübertragung kommt. Unswar hab ich das komplette MCP mit aktuell 26 Inputs (alle mit Event ID) und 24 Outputs aktiviert. Es kam zu keiner Fehlübertragung, bin auch so eine Stunde geflogen, hat alles super geklappt.
Das wollte ich euch nur mitteilen :)
Einen schönen Sonntag Abend wünsche ich allen,


Gruß

Fusa
2016-01-24 17:14
Avatar
teufellukas
Posts: 1
Hallo zusammen,

bis jetzt habe ich nur lesend teilgenommen und da ich nicht viel neues beizutragen habe, fasse ich mich auch kurz.
Ich kann eure Beobachtungen bei mir nur bestätigen. Ohne Logging und mit Logging Log Level Info gehen etwa 15% der Inputs im FSX verloren. Mit eingeschaltetem Logging Log Level Debug kommen 100% der Inputs im FSX an. Wenn die (zeitaufwändige) Textausgabe der einzige Unterschied ist, dann kann es sich nur um ein "Zeitproblem" handeln.

Auch wenn der Fehler mittlerweile praktisch auf die Verbindung zwischen FSUIPC und MobiFlight eingegrenzt wurde, habe ich zwischenzeitig anstatt des Tasters eine Rechteckspannung, generiert durch einen zweiten Arduino, verwendet, um Probleme durch Prellen des Tasters auszuschließen. Selbe Symptomatik.

Viele Grüße
Lukas
2016-01-25 16:07
Go to page 1Go to page 21234Go to page 4Go to page 4