MobiFlight Community Support

Danke !

Dann kann ich zum Problem selbst noch etwas beisteuern.... Hab heute in der Arbeit mal drüber nachgedacht was ich gemacht habe, damit das Problem bei mir weg war.....

1. Debug
Das aktivieren des Debug hat damals das Problem massiv verstärkt. Der Ansatz ist also durchaus richtig. Wenn der Modus an ist verursacht das diese Probleme auch !
Aber auch OHNE Debug Modus waren die Fehlübertragungen noch da (wenn auch weniger)

2. FSUIPC Intervall
Hier habe ich damals keine Besserung gemerkt. Egal ob 100ms , 300ms oder ein höherer Wert.

3. Systembereinigung (Defrag, Etwa 200gb an Deinstallation, Virenscan, Registry Säuberung mit CC Cleaner)
Mir ist heute eingefallen das ich zu der Zeit als die "Fehler" verschwunden waren nicht nur MF Version 6.3 installiert hatte sondern in der Nacht zuvor meine Jährliche "Systemwäsche" gemacht habe.
Kann also nicht ausschließen ob vielleicht das Säubern des Systems die Fehler bereinigt hat und nicht die Installation von 6.3.

Reproduzieren kann ich es nicht, da die Fehler seitdem komplett weg sind !

mfg.

Hallo,

ich nehme an, mit 'Debug' ist das Logging in FSUIPC gemeint. Hab ich soeben getestet. Das Logging verschlimmert die Situation extrem, ritt aber wie beschrieben auch obne Logging auf.
Meine Schalter hab ich aus einem lokalen Elektronikgeschäft, ich denke aber, dass die baugleich mit den Chinateilen sind.
Ich sollte vielleicht auch erwähnen, dass ich einen ziemlich alten Rechner hab. Das könnte auch der Grund sein, warum das Problem nur bei mir auftritt. Ich hatte ohnehin vor in den nächsten Wochen oder Monaten eine stärkere Maschine anzuschaffen.

Grüße

mit Logging ist das Logging im MFConnector gemeint. Einstellungen -> Allgemein

Ich benutze auch die billigsten Schalter, die ich so finden kann

Mein Rechner ist ziemlich fix, aber der MF Connector braucht bei mir wirklich nur ca. 1-2% CPU. Ich würde mich wundern, dass das daran liegt.
Tauchen denn alle Schaltvorgänge im Debug-Log auf? Wenn ja, dann gehen die zwischen MF Connector und FSUIPC (oder da) verloren. Wenn nein, dann liegt das Problem entweder auf der USB-Verbindung (was ich nicht glaube) oder eventuell sogar an der Verkabelung? Ist letzteres ausgeschlossen? Ist es auch unzuverlässig wenn nur ein Schalter konfiguriert ist?

Hallo nochmal,

Logging war immer deaktiviert. Mit aktivem Logging ändert sich die Situatuon nicht wesentlich.
Die Schaltvorgänge werden im Mobiflight Logging stets erkannt. Bei den Fehlübertragungen kommen sie im FSUIPC Log nicht an.

Ich hab jetzt alle programmierten Inputs und Outputs deaktiviert und dann surzessive reaktiviert. Fazit: Das Problem tritt erst auf, sobald die erste Ausgabe aktiviert wird, sprich das Häkchen gesetzt ist. dabei ist es unerheblich ob eine LED an ist oder nicht. Es können alle Inputs aktiv sein, solange kein Output aktiv ist, läufts tadellos. Mit der ersten LED oder 7-Segment Ausgabe ist das Problem voll da. Daraus schließe ich, dass es mit Sicherheit nicht an der Verkabelung liegt.

Noch eine Beobachtung: Ich prüfe den Offsetstand von 0810 mit einer LED. Schalter ist auf AN, Offset =1, LED ist AN. Wenn ich den Schalter auf AUS stelle geht die LED manchmal ganz kurz aus und dann wieder an. Im FSX ist aber nichts zu erkennen. D.h. das Offset wird für einen kurzen Augenblich auf 0 gestellt, hüpft dann aber wieder auf 1.

Grüße

Super, das mit dem systematischen Vorgehen (alle Zeilen aus und dann einzeln an, solange bis der Fehler gefunden ist) klappt bei mir oft auch am besten!

Wie ist denn die Verkabelung von LEDs und den Schaltern gelöst? Verwenden die einen gemeinsamen GND? Ich würde nämlich aktuell ein elektrisches Problem _nicht_ ausschließen.

Hast Du es denn schon mal mit einem anderen Offset ausprobiert?
Eventuell "übersteuert" ja ein Mechanismus den Autothrottle ARM?
Fang z.B. mal mit den Lights an...
Du kannst auch mal probieren, via FSUIPC Offset den Status zu lesen aber via Event ID den Status zu schreiben. Damit stellst Du nochmal explizit sicher, dass es keinen Konflikt beim Schreiben/Lesen gibt - wobei ich mir das eigentlich auch schwer erklären könnte...

Hallo zusammen,

bei mir verwenden alle Taster, Schalter, LEDS und Max7219 einen gemeinsamen GND. Falls Tests oder Logs von mir gewünscht sind sagt einfach bescheid, hoffe wir finden das Problem bald.


Gruß

Fusa

Hallo,

ich hab jetzt allerhand ausprobiert. Andere Offsets, Pins für andere Geräte ausstecken, Schalten per Ein- und Ausstecken der Pins. Nichts führte zu einer Verbesserung. Ich bin mir ziemlich sicher dass es an meinem alten PC liegt, daher nehm ich das zum Anlass und gönn mir einen Neuen. Ich werd Euch jedenfalls über weitere Entwicklungen berichten.

Die 5 GND Pins am Arduino hängen doch alle zusammen, also macht es m.M. keinen Unterschied ob die GND zusammenhängen, oder?

Grüße

Hallo,

am langsamen Rechner kann es bei mir nicht liegen, der ist was die Hardware betrifft recht Fix.

Also ich kann mir das irgendwie nicht erklären... von daher brauchen wir noch ein bisschen Geduld um die Ursache zu finden.

@all: Jetzt nochmal die Frage: klappt es bei Defaultfliegern auch nicht? Bitte unbedingt mal das Parkingbrake Beispiel aus den Tutorials machen. Und zwar für Schalter und LED. Ich vermute weiterhin, dass es ein elektrisches Problem ist. Verwendet ihr eine externe Stromversorgung? Bitte mal eine Skizze zur Verkabelung teilen.

Ich verwende drei geätzte Platinen (MCP1-3) und zwei Arduino Mega Boards. Die Platinen MCP1 und MCP2 sind an Arduino Mega Board 1 und MCP3 an Arduino Mega Board 3 angeschlossen. Zur Verkabelung sind Wannenstecker an den Platinen platziert, sie heißen Ardu1, Ardu2 usw, von denen gehen Flachband- oder Jumperkabel an die Arduino Boards.
Eine externe Stromversorgung ist nicht angeschlossen.

Hier der Link zu den Schaltplänen und der Pinbelegung.
https://drive.google.com/folderview?id=0B4PQzbav2dY7ejhHWTBMVVJhS00&usp=sharing

Mit dem Defaultflieger 737 -800 treten die Fehler auch auf. Beim test waren alle Inputs und Outputs bis auf Parkbremseschalter und LED deaktiviert.
Werden alle Outputs deaktiviert, kommt es zu keiner Fehlübertragung.


Gruß

Fusa

Coole Sache das mit den Platinen. Wie hast du die hergestellt?

Hast du mal Schalter und LED direkt ohne deine MCP Platinen angeschlossen und besteht dabei auch das Problem?

Ich möchte durch diesen Test ein elektrisches Problem auf den Platinen ausschließen.

Hallo Leute....

Muss mich leider jetzt auch wieder unter die Bug geplageten einreihen !

Nachdem Fischhons das angesprochen hat mit den "Outputs" habe ich auch das nochmal rekapituliert..... Ich habe ja noch kein fertig verbautes Element sondern habe bisher mit Mobiflight nur die einzelnen Elemente getestet bevor ich mit dem bauen wirklich anfange.....
Und genau da liegt die Ursache warum meine Probleme scheibar weg waren..... Ich habe seitdem keinen gemischten Aufbau mehr gehabt. Mein EFIS Testodul besteht nur aus schaltern und mein MCP Testmodul nur aus 7 Segmentern und ein paar LED.

Aufgrund des Postings hier hab ich auf mein EFIS Board die letzten freien Pins Testhalber mit einen 7 Segment und 6 LED´s belegt.... Und siehe da.... Die gleichen Fehler wie früher !

Was komisch ist..... Der Debug Mode von Mobiflight (Logging-Debug) ist aber jetzt eher Positiv. Ist dieser aktiviert habe ich eigentlich keine Fehler trotz gleichzeitigen In und Outputs.
Deaktiviere ich den Logging Mode, dann haben die Schalter wieder einige verschluckte Befehle. Kann also nicht sagen ob MF die Komandos abgibt da beim aktiven Logging keine Fehler vorkommen !
Sind keine Outputs aktiviert funktioniert mein Aufbau fehlerfrei !


Eine Sache ist mir allerdings aufgefallen.....
Laut FSUIPC habe ich auch wenn keine Outputs aktiviert sind trotzdem bei den Schalterbefehlen Sowohl einen Write als auch einen Read.
Also Offset 3110 und 3114 werden beide gelesen und geschrieben.

Aktiviere ich nun einen Output (z.b. eine LED) dann wird unter Read in FSUIPC etwas komisches angezeigt....
Es wird natürlich dauerhaft der Zustand des Offsets der LED abgefragt... Aber auch ununterbrochen der Offset 3110 und 3114 (Auch ohne das der Schalter bewegt wird)

Frage: 1. warum wird überhaupt 3110 und 3114 ausgelesen bei einen Write vorgang ??
Und 2. Warum werden diese beiden dauerhaft ausgelesen wenn ein weiterer Output dabei ist ?

Hallo zusammen,

das ist ja wirklich sonderbar und ich werde es mir am Wochenende in Ruhe anschauen.

Ich hab einen gemischten Aufbau zum Testen und mir war so ein Verhalten bisher nicht aufgefallen. Da es sich jetzt aber offensichtlich häuft gibt es vielleicht einen Grund den ich übersehe.

Also, am Wochenende sind wir hoffentlich schlauer.

In der Zwischenzeit bitte ich Euch dennoch mit der Ursacheneingrenzung weiter zu machen. Das hilft mir eventuell den Grund schneller zu finden.

Muss man schnell hintereinander den Schalter bewegen oder gehen auch bei normaler Verwendung Stellungen verloren?