MobiFlight Community Support

So, Dank deiner Hilfe funktionieren die beiden ADF´s jetzt, besten Dank auch!

Ich habe mir nun den Ecoder zur Brust genommen. Logging war aber schon aktiviert, habs auch mal abgeschalten, hatte aber keinen Einfluss. Mit einer neuen Config, welche nur den Encoder enthält, funktioniert es etwas besser. Allerdings habe ich auch hier Aussetzer. Zwei Raster sind aber immer mindestens nötig, um ein Event auszulösen.
Einen Verdrahtungsfehler schließe ich mal aus, denn dann gäbe das mit Sicherheit ein anderes Fehlerbild. Gut, der Encoder könnte einen Defekt haben, das kann ich momentan noch nicht ausschließen. Die Verkabelung zum Arduino ist auch nicht besonders lang um da eine Fehlerquelle vermuten zu können.

Vielleicht sollte ich den Encoder mal auf den BU0836 legen und die 2, bzw. 4 Buttons in FSUIPC zuweisen. Mal sehen wie der ELMA dann reagiert. Auf meinem Radio ist auf der linken Seite noch ein Einzel-Encoder mit 30 Rastern verbaut, aber mangels sinnvoller Funktion habe ich den noch nicht angeschlossen. Das könnte ich aber mal machen, nur um zu sehen, wie der mit MF reagiert.

Gruß, Gert

Vielleicht sollte ich den Encoder mal auf den BU0836 legen und die 2, bzw. 4 Buttons in FSUIPC zuweisen. Mal sehen wie der ELMA dann reagiert.
Gruß, Gert

Ich hab mir mal das Datenblatt eines Elmas angesehen... weis natürlich nicht welchen du genau hast !
z.b. http://www.leobodnar.com/products/BU0836X/ELMA-E37.pdf

Das folgende sollte dir bitte einer der Elektronik Freaks hier im Forum bestätigen......

Der Elma hier hat laut Datenblatt stets ein verhätlnis von Rastung und PPR (Pulses per Revoulution) von 2:1 ... Also z.b. 16 Rastungen 8 Pulse.
Alle Billigencoder wie die Alps die ich verbaut habe bisher hatten ein verhältins von 1:1 .... wie dieser 24/24 Encoder https://www.reichelt.de/Drehimpulsgeber/STEC12E07/3/index.html?ACTION=3&LA=2&ARTICLE=73922&GROUPID=3714&artnr=STEC12E07&SEARCH=%252A

Wie gesagt... Da bin ich noch nicht so der Profi..... Das könnte aber "logisch" gesehen durchaus damit zusammenhängen.

EDIT: Bei LeoBodnar steht auch in der Beschreibung : "- 2 pulses per detent - 1:2 mode in our encoder config software"
Womöglich gleichen die das in der Software wieder aus.... Mobiflight ist aber vielleicht anders ausgelegt.
Könnte nochmal ein ein Thema für Sebastian sein !

Ja, es ist der ELMA-E37 und man muss den in dem Configurations-Tool von Bodnar auf 1:2 stellen. Ich befürchte fast, dass man beim E-37 + MF eine Hardwarelösung braucht und dann Buttons als Eingabe hernimmt. Wäre natürlich super, wenn MF eine Softwarelösung dafür anbieten würde. Ist eben nur die Frage, wie groß der Programmieraufwand letztendlich ist und ob es sich lohnt, wegen ein paar ELMA-Nutzern das zu intergrieren. Angesichts des Preises, nutzen wohl die meisten eine Bastellösung mit 2 günstigen Alps o.ä.
Die hatte ich ja ursprünglich auch, sieht man auch auf einem der beiden Bilder, aber das wollte ich mir nicht mehr antun - war von Anfang an eine wacklige Geschichte. Hatte aber auch blöderweise ein 0.5 Modul Zahnrad verwendet, da muss man viel zu genau arbeiten. Dazu kommt, wenn man das mal gegenrechnet, 2 Alps, zwei Achsdurchführungen, 2 Wellenverbinder, 2 Zahnräder, dazu noch die ergrauten Haare man beim Zusammenbau bekommt, ist da unterm Strich nicht mehr so viel gespart.

Mal abgesehen vom Encoderproblem, funktioniert mein Teil inzwischen richtig gut. Für den Transponder habe ich den Push-Button des ELMA´s genutzt, um so zwischen Stelle 1 / 2 und 3 / 4 umschalten zu können. Das reduziert die Dreherei auf ein erträgliches Mass. Würde ich nun den Encoder auf den BU0836 auslagern, müsste ich in der FSUIPC ini Bedingungen anlegen, damit alles wieder funktioniert. Von daher würde ich es schon vorziehen, wenn alles in MF bleiben könnte. Vielleicht findet sich ja noch eine Lösung.

Viele Grüße

Gert

Hi Gert

Ich selber habe auch einen Alps Encoder der sich so verhält und hatte schon mal versucht das Verhalten zu verbessern - ich hatte versucht die Signale anders auszuwerten aber war nicht erfolgreich gewesen.

Mich stört es aktuell nicht so sehr zwei Rastungen zu drehen um eine Änderung herbeizuführen. Was mich wundert ist, dass das nicht zuverlässig bei dir geht.

Eventuell hilft der Debug Mode Trick den Pizman erwähnt hat, aber ich glaube eher nicht.

Ich mach mich nochmal schlau wie man dem ganzen auf Hardwareseite gerecht wird und hoffentlich kann ich das dann in MF als Option anbieten.

Hi Gert

Wo kann ich die tasten mit leds finden, ich suche die seit langem im internet, finde sie aber nicht. Ich haette sie gerne on my radiostack benutzt.

Danke AlbEagle

@ Sebastian/Gert

Muss nochmal was anfügen....
Das mit den "immer" 2:1 war falsch.... Im Datenblatt sieht man ganz unten das es auch Dual Encoder von Elma gibt die über ein 1:1 System arbeiten Dummerweise gibt es offenbar aber auch welche mit 4:1.

Somit ist die Frage wie aufwendig hier eine Softwarelösung ist.... Vermute das ist eine Library im Programm die den Encoder GreyCode auswertet... Hab da keine Erfahrung ob es diese auch für 1:2 oder 1:4 gibt bzw eine die alle 3 varianten kann.

Im Gegenzug... Das drehen über 2 Raster ist akzeptabel.... Ich wär trotzdem für ne Option, aber nur wenn es wenig Aufwand bedeutet ( Dann vielleicht gleich auch für die 4:1 )

*************
@ Albeagle. Jepp das hab ich mich auch gefragt..... Die sieht man so oft auf Bildern von Homecockpits aber ich hab noch keinen Shop gesehen der die hat. Passen auch sehr gut zum Honeywell MCP für die B737

@ Sebastian

Du brauchst also auch 2 Raster pro Event, aber hast keine Aussetzer? Wenn bei mir diese Aussetzer nicht wären, dann wäre es auch nicht so schlimm. Ich werde mal die Verkabelung überprüfen, vielleicht ist da ja der Wurm drin.
An zwei Raster kann man sich ja noch gewöhnen, aber falls Du dazu noch eine Lösung findest, wäre das natürlich super.

@ Albeagle

Also die Tasten mit den grünen und roten LED´s habe ich bei Conrad bestellt - allerdings war das vor weit über 10 Jahren. Habe sogar noch die alte Bestellung gefunden, die Artikelnummer ist 701157 - U0 für den grünen Taster. Leider hat die Suche ergeben, dass der Artikel ausverkauft ist.
Ich bräuchte selbst noch Taster in dieser Größe für ein EFIS, wobei eine LED da nicht notwendig wäre. Leider funktioniert die Seite von Conrad bei mir nicht richtig, keine Abbildungen, das macht eine Suche dort zum Albtraum.

@ Pizman

Den E-37 gibt es wohl in folgender Ausführung: detent/pulses per rev. (PPR) 32/16, 32/8, 16/16, 16/8. Das Datenblatt zeigt auch ein "Recommended Interface" mit Pullup Widerständen auf VCC und einem 74HC14 (Hex inverted Schmitt-trigger)
Was passiert eigentlich elektrisch an einem Arduino-Pin. Liegt dort bei Encodern eine Spannung am Eingang an, welcher dann auf Masse gezogen wird?

Gruß, Gert

Was passiert eigentlich elektrisch an einem Arduino-Pin. Liegt dort bei Encodern eine Spannung am Eingang an, welcher dann auf Masse gezogen wird?
Gruß, Gert

Jetzt wirds technisch :-)

Für genauere Erklärung solltest du Google bemühen....
Grob:
Der Pin kennt nur High oder Low... An oder Aus oder softwaretechnisch dann 1 oder 0.
Der Encoder sendet also an die Pins entweder Spannung oder eben keine ( Oder setzt diese auf GRD.... Da bin ich zu wenig Elektriker um das genau zu defineiren) . Und die Software errechnet anhand dieser Information dann ob der Encoder gedreht wurde.

Würde nun der Encoder bei einer Drehung schlicht die Spannung umkehren.... Also erst haben wir: PIN-A = 1 .. PIN-B = 0 , und danach PIN-A = 0 .. PIN-B = 1 DANN erkennt die Software zwar das geschalten wurde.... Sie würde aber nicht verstehen ob der Encoder Links oder Rechts gedreht wurde !

Deshalb benutzt ein Encoder einen "Code" den du im Datenblatt siehst. Dabei werden die Daten im Takt sozusagen "versetzt".... Als Ergebins können jetzt VIER Zustände existieren... AN-AN .... AN-AUS ....AUS-AUS .... AUS-AN !
Jetzt ist es also Möglich anhand 2 Inforamtionen ( dem Zustand der Pins VOR der Drehung und NACH der Drehung ) Genau zu bestimmen ob Rechts oder Links herum gedreht wurde. ( Diese Berechnung wird durch die Library gemacht, die in Mobiflight eingebunden ist.)

Ich sehe also das Problem das ein 1:2 bzw ein 1:1 Encoder einen anderen Vorgang verursachen.... Sprich der 1:2 macht in 2 Rastungen das selbe das ein 1:1 Encoder mit einer Rastung vollzieht....
Die Information die er liefert würde aber reichen um die Richtung auch bei einer Rastung zu berechnen.... Nur müsste die Software das nun anders auswerten !

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

Und zu deinen Fehlern......

Auch wenns jetzt sicher nicht die 100% Lösung ist.... Hast du schon mal versucht den FSUIPC Intervall zu verändern ? Einfach mal testen.