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.

icon
Avatar
Gemu
Posts: 101
Ich befasse mich gerade etwas mit IFlyToFSUIPC und habe auch schon ein paar Funtionen auf Schalter gelegt. Allerdings habe ich die bislang nur direkt in FSUIPC via HID-Controller zugeordnet.

Mich würde jetzt natürlich interessieren, wie sich IFlyToFSUIPC in Verbindung mit Mobiflight verhält. Um das mal zu testen, habe ich versucht die 3 Led´s für Gear Green, die bislang über die FS-Default Offsets angesprochen werden, auf die IFly-Offsets zu ändern. Der Versuch scheiterte kläglich - allein schon daran, dass ich nicht ganz durchblicke wie das in MF eingetragen werden muss.

Im Manual von IFlyToFSUIPC steht nur:

Outputs
– 0x9402 – 0x9427 Offsets for lights. Every bit in these offsets represents one led output.

– 0x9430 – 0x9470 Offsets for numerical info. These offsets maps to digital outputs in iFly.

If The value is 65535 then related digital output must be blank. Any other value means the actual number in the output.– 0x9472 – 0x94EF General output offsets.


In der Liste finde ich dann folgende Werte:

941E 1 NOSE_GEAR_GreenLight_Status

941E 3 LEFT_GEAR_GreenLight_Status

941E 5 RIGHT_GEAR_GreenLight_Status

1, 3, und 5 wären dann die relevanten Bits des Offsets. In MF muss ich 3 Dinge eintragen. Das Offset selbst, die Byte-Größe und die Bitmaske.
Ich habe mir das FS-Default Preset von Nose_Gear (0x0BEC) mal angeschaut, um so eventuell hinter das Geheimnis der Bitmaske zu kommen. Da ist Byte 1 und 2 komplett angehakt, Byte 3 und 4 sind leer.
Nach meinem Verständnis interpretiere ich das so, dass von den 4 Bytes, Byte 1 und 2 komplett maskiert sind und nur Byte 3 und 4 gelesen werden können. Weshalb das so ist, erschließt sich mir nicht.
Doch um das auf IFlyToFSUIPC umzumünzen, müssten dann doch bei Nose_Gear (941E) alle Bits ein Häkchen bekommen außer Bit 1. Das funktioniert aber nicht, aber ich weiß ja noch nichtmal wieviel Bytes ich bei Size angeben muss. Wer kann mir dabei auf die Sprünge helfen?

Grüße
Gert
2018-01-31 19:40
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
Hi

Du vermischt hier einiges !
Wenn du nur dein problem lösen willst dann spring zu Punkt 2. Falls du das ganze verstehen willst lies auch Punkt 1 !

1. Der Preset und das System.
Wie oft geschrieben sind die Presets ein Überbleibsl aus der Anfangszeit. In diesen Fall ist es etwas verwirrend da Sebastian hier tatsächlich Byte 1 und 2 maskiert hat obwohl dies eigentlich nicht nötig wäre. Um den Sinn darin zu verstehen muss man sich etwas mit Binär Rechnung und mit FSUIPC selbst auskennen.
Für besagten Offset steht in der FSUIPC Liste folgendes....
iconQuote:

Offest: 0BEC.... Size in Byte:4 .....Gear position (nose): 0=full up, 16383=full down


Das ganze ist also Offiziell ein 4 Byte Offset und der Wert kann zwischen 0 (UP) und 16383 (DOWN) liegen. Man sollte wissen das Pete Dowson diese Offsets vor vielen Jahren vergeben hat.... Und damals gab es noch keine AddOns. Folgerlich hat er nicht gespart und der Ordnung halber meist 4 Byte Offsets verwendet ( Auch wenn er die gar nicht gebaucht hätte).... Der Wert 16383 ( Höher kann er nicht sein laut Liste) ist binär gesehen "0011 1111 1111 1111"
Folgerlich.... Die Bytes 3 und 4 werden niemals benutzt da der Wert im höchsten Fall nur 14 Bits ( weniger als 2 Bytes) braucht.
Deshlab funktioniert auch die Maskierung von Sebastian da wie gerade erklärt die Bytes 3 und 4 sowieso "leer" sind.
Theoretisch könnte man hier auch als Size nur 2 Byte angeben.... Kommt auf das gleiche raus.

In FSUIPC gibt es viele Beispiele wo man "effektiver" arbeiten kann indem man die Size kürzt oder andere Offsets als Startpunkt nimmt.... Aber im Zweifel verwende das was in der Liste steht wenn du das System nicht durschaust. Denn das geht immer !


*****
2. Dein Programm.
Vorweg: Damit hab ich noch nicht gearbeitet... Kann dir also nicht sagen ob die Daten "perfekt" sind. Aber die kurzbeschreibung ist ansich selbstverstehend !
iconQuote:


0x9402 – 0x9427 Offsets for lights. Every bit in these offsets represents one led output.
......
941E 1 NOSE_GEAR_GreenLight_Status
941E 3 LEFT_GEAR_GreenLight_Status
941E 5 RIGHT_GEAR_GreenLight_Status



Um das umzusetzen brauchst du DREI Configs ( Denn jede LED muss ja eigenständig angefahren werden)
Beispiel: Nose Gear.
Du erstellst eine OUTPUT Config
Offset ist 941E .... Size ist 1 Byte .... Bitmask ist 1 Hacken bei Bit 1 ALLE anderen Hacken müssen leer sein. ( Du willst ja nur den Bit lesen der das NoseGear anzeigt !)
((Wichtig: Ich sehe deine Liste nicht komplett sondern nur was du hier kopiert hast..... Normal sind Bits immer von 0-7 Also der niedrigste Bit (Rechts) ist 0... Der Links daneben ist 1 usw. Ich HOFFE deine Liste arbeitet auch so. Falls die geschlampt haben und die Bits mit 1-8 bezeichnen ( unprofessionell aber manche machen das) dann musst du umdenken... Als 1 wäre dann 0... 2 wäre 1 usw. Bitte prüfe das !))
Compare etc brauchst du nicht !
Ist die Funktion AUS dann hat der bit einen Wert von 0 Also auch deine Config ist 0 und die LED ist aus !
Ist die Funktion AN dann hat der Bit einen Wert von 1. Die Config hat einen Wert je nach position des Bits.... Bit 0 = 1 ... Bit 1 = 2.... Bit 2= 4.... Bit 3= 8 usw.... DAS ist aber egal den deine LED leuichtet immer wenn der Wert größer 0 ist. 0=Aus Jede andere positive Zahl = An !

Für die anderen Gears machst du das selbe....
Wieder eine Output Config.... Gleicher Offset und gleiche Größe .... Nur bei der Bitmask nimmst du jetzt den anderen Bit den du dafür brauchst und achtest darauf das wieder ALLE anderen nicht ausgewählt sind !

Denke das sollte reichen fürs erste.... Falls noch Fragen sind schreib einfach !
Good Luck !
2018-02-01 11:55
Avatar
Gemu
Posts: 101
Hallo Pizman,

jetzt ist mir einiges klarer.

iconQuote:

Bitmask ist 1 Hacken bei Bit 1 ALLE anderen Hacken müssen leer sein



Verstehe, das ist also keine Bitmaske, sondern eine Unbitmaske. :)
Ich bin ja davon ausgegangen dass das Häkchen maskiert und hatte dementsprechen alle Bits angehakt außer 1.

iconQuote:

Falls die geschlampt haben und die Bits mit 1-8 bezeichnen ( unprofessionell aber manche machen das) dann musst du umdenken... Als 1 wäre dann 0... 2 wäre 1 usw. Bitte prüfe das !))


Das ist schon richtig so.

0x941E 0 NOSE_GEAR_RedLight_Status
0x941E 1 NOSE_GEAR_GreenLight_Status
0x941E 2 LEFT_GEAR_RedLight_Status
0x941E 3 LEFT_GEAR_GreenLight_Status
0x941E 4 RIGHT_GEAR_RedLight_Status
0x941E 5 RIGHT_GEAR_GreenLight_Status
0x941E 6 AUTO_BRAKE_DISARM_Light_Status
0x941E 7 ANTISKID_INOP_Light_Status

Ich teste das gleich mal aus. Dank deiner Hilfe, erwarte ich nun keine Ungereimtheiten mehr. Besten Dank dafür!

Gert
2018-02-01 18:42
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
iconGemu:


Verstehe, das ist also keine Bitmaske, sondern eine Unbitmaske. :)
Ich bin ja davon ausgegangen dass das Häkchen maskiert und hatte dementsprechen alle Bits angehakt außer 1.



Über die Bezeichnung hab ich nie nachgedacht.... Mask----maskieren bzw maskiert etc.
Für mich war das selbsterkärend... Ich will Bit X lesen also mach ich einen Hacken bei Bit X und sonst nirgends ( bzw nehme die vorhandenen Hacken raus.
Man könnte auch drauf kommen das standardmäßig ALLE Hacken gesetzt sind.... Und dabei ja der ganze Byte ( also alle 8 Bits) gelesen werden.
Aber EGAL ! ;)

Noch kurz Zwei Infos damit du nicht in ne Sackgasse läufst.

1. Das Lesen mehrerer Bits ist Möglich.... Du kannst also mehrere Hacken setzten und so z.b. Bit 0-3 lesen. Z.b. sehr Sinnvoll wenn du wissen musst ob eine von 4 Functionen an ist.... Wenn die Bits nebeneinander liegen liest du alle 4.... Ist der Wert 0 sind ALLE aus.... Ist der Wert >0 dann ist mindestens eine funtion an !
ABER: das SCHREIBEN ist nur auf EINEN Bit möglich.... Bei INPUTS darfst du in Mobiflight nur einen Bit maskieren !

2. Wie oben angesprochen ist der Config Wert eines maskierten Bit nicht zwingend 0 oder 1.....
iconpizman82:


Ist die Funktion AN dann hat der Bit einen Wert von 1. Die Config hat einen Wert je nach position des Bits.... Bit 0 = 1 ... Bit 1 = 2.... Bit 2= 4.... Bit 3= 8 usw.... DAS ist aber egal den deine LED leuichtet immer wenn der Wert größer 0 ist. 0=Aus Jede andere positive Zahl = An !


DAS liegt daran, da Mobiflight den Offset trotz der Bitmask immer noch als BYTE sieht.... Angenommen du maskierst nur den Bit 3 xxxx ?xxx .... Dann Sieht Mobiflight die nicht gewählten Bits als NULL .... Also 0000 ?000 . Ist nun der Bit High (1) dann sieht es so aus 0000 1000. und DAS ist aber Decimal 8.
Wenn du also den Bit3 verwndest und er ist an dann hat die Config einen Output Value von 8 ( und nicht wie instinktiv gedacht von 1)
WICHTIG: Wenn du so ne Config als Precondition verwendest musst du das einbeziehen und dort sagen "Arbeite wenn config XY=8 "
Natürlich könntest du auch sagen " Arbeite wenn Config XY >0 " Oder du kannst in der Config einen Compare machen und sagen "Wenn 8 dann 1 sonst 0"

Bitte das beherzigen.... Das erspart dir viel Ärger.... Hing damals auch viele Stunden dran bis ich das verstanden habe !
Good Luck !
2018-02-02 23:05
Avatar
Gemu
Posts: 101
Danke für die Beschreibung der Sackgassen. Die ersten LED´s haben jedenfalls gleich auf Anhieb funktioniert. Wenn ich zu den Displays komme, melde ich mich sicherlich wieder. :D
2018-02-04 23:36
icon