Homecockpit Bauer

[mip]

Hallo liebe Leute!

Vielleicht darf ich mich kurz vorstellen: Mein Name ist Michael, ich bin 39 Jahre alt und wohne in Graz (Österreich). Ich bin eigentlich schon seit meiner Kindheit begeisterter Flusianer (seit FS4) und habe dies auch bis heute beibehalten (soweit es die Zeit zugelassen hat).

Ich habe auch bereits ein bisschen angefangen, ein Homecockpit zu bauen (Saitek Yoke, Rudder und Throttle), aber jetzt möchte ich mehr…

Mein Ziel ist es, ein (halbwegs) realistisches Homecockpit einer B737 nachzubauen. Es soll nicht bis ins kleinste Detail simuliert werden, sondern mich einfach beim Fliegen unterstützen. Derzeit verwende ich die PMDG 737 und den FSX. Als Grundlage habe ich die Maße eines B737-Cockpits hergenommen und diese nach meinen Vorstellungen adaptiert. Es wird auch „nur“ ein Single-Seat, mehr Platz habe ich nicht im Keller (außerdem wird es dann auch ein bisschen billiger). Irgendwann sollte es dann einmal wie folgt aussehen (sorry für die Bezeichnungen im Modell, wusste aber nicht wie man die wieder wegbekommt):

Beginnen werde ich mit dem MIP, dann das Glareshield, Overhead und zum Schluss das Pedestal. Einen Zeitplan gibt es nicht, wie heißt es so schön: der Weg ist das Ziel…

Mein Plan ist es, die Schalter über die Opencockpits Karten, SIOC und FSUIPC mit dem Flusi bzw. mit PMDG zu verbinden (eigentlich so wie es auch Urs hier im Forum macht). Und daher nun zu meinen Fragen:

1. Ich bin noch etwas unschlüssig ob ich die Panels + Komponenten bei Hispapanels oder bei Opencockpits bestelle. Das Prinzip von Hispapanels (Schalter werden auf eine PCB gelötet) gefällt mir sehr gut (ist aber dann auch teurer). Bei Opencockpits denke ich, dass da mehr Zusatzarbeiten notwendig sind (d.h. irgendwo müssen die Schalter ja angebracht werden, hier wird ja bei Opencockpits eigentlich nichts angeboten, außer die Panels und Schalter). Vielleicht könnt ihr mir hier ein paar Erfahrungswerte geben?

2. Sind die PCB’s von Hispapanels mit SIOC kompatibel? Ich denke mal ja, weil ich glaube Urs hat auch diesen Weg gewählt.

3. Sind die Panels von Hispapanels und Opencockpits von den Farben her gleich? Bei Hispapanels werden die Farben der Panels immer angegeben, bei Opencockpits leider nicht. Ich möchte hier eigentlich vermeiden, dass die Panels dann von der Farbe her unterschiedlich sind.

4. Macht es bei einigen Komponenten Sinn, diese gleich als Plug-und-Play Variante zu kaufen? Auf alle Fälle werde ich den Throttle fertig beziehen, hier fehlt mir das handwerkliche und technische Geschick, dieses als DIY zu realisieren. Ich habe schon öfters gelesen, dass das MCP auch schwieriger ist zusammenzubauen und dass sich hier der Aufwand nicht lohnt.

5. Wie sieht es mit den LED’s von Opencockpits/Hispapanels aus? Habe gelesen, dass diese eher schwach leuchten.

6. Gibt es von euch einen Tipp, welche Litzenkabeln ich für die Verbindungen verwenden soll? Ich habe noch welche mit 0,22 mm² zu Hause, viele meinen aber dass 0,5 mm² besser wären.

7. Welchen Lack habt ihr für euren Aufbau verwendet? Ich tendiere hier zu einem wasserbasierenden Acryllack.

Ich weiß, Fragen über Fragen, aber ich hoffe, jemand von euch erbarmt sich, mir hier ein paar Antworten zu geben.

Vielen lieben Dank schon mal im Voraus!

LG

Michael

[Alpin-Flier]

Hallo Michael

 

Sehr schön, dass es wieder einen Cockpitbauer mehr gibt . Es hat wahrscheinlich gar nicht so viele, die ein solches Abenteuer durchziehen. Darum wünsche ich Dir viel Durchhaltewillen, aber auch viel Spass dabei. Wie ich es gemacht habe, hast Du ja schon mitbekommen. Allerdings würde ich heute bestimmte Dinge anders machen. Deshalb versuche ich mal, Deine Fragen aus meiner Sicht zu beantworten.

 

1.
Der mechanische Aufbau von Hispapanels ist sehr schön gemacht. Dazu gehören die über einen Bus (Flachbandkabel) mit dem Master verbundenen IO- und Anzeigenprints. Auch die Verbindungen zu den speziellen Prints für MCP und MIP sind mittels Flachbandkabeln sauber ausgeführt. Es gibt auch keine geschalteten Massen, was die Verdrahtung sehr einfach macht. Die Verbindung zum PC erfolgt über eine einzige USB-Schnittstelle der Masterkarte, nur Servoplatten brauchen je eine eigene USB-Verbindung. Die Bausätze sind bis auf Knöpfe und teilweise Montagebolzen komplett und können ohne grössere Kenntnisse zusammengebaut werden.
Aber:
Es sind längst nicht alle Bausätze für die notwendigen Module vorhanden, insbesondere im Pedestal und sicher auch im Overhead. Und software-mässig stehst Du in der Wüste... Zwar ist die verwendete Software SC-Pascal lernbar (ohne Scripts geht nichts), aber Unterstützung bekommst Du nicht. Take it or leave it... Eigentlich jammerschade um die schöne Hardware .

 

Opencockpits hat einen etwas anderen Ansatz, der allerdings schnell zu einem riesigen Kabelverhau führt. Schau nur mal in ein fertiges Overhead dieser Firma. Andererseits bieten sie die meisten Geräte relativ günstig und fixfertig mit je einer eigenen USB-Schnittstelle an. Hier ist die Verdrahtung also wieder sehr einfach. Mir gefallen auch die kompletten Overheads (foreward, backward), die eine Menge Arbeit ersparen. Klar, das kostet einiges, aber man kommt dann wenigstens wieder innert nützlicher Zeit zum Fliegen und gibt nicht vorzeitig auf.
Dazu kommt eine relativ gut unterstützte Software namens SIOC. Da habe ich zwar auch schon negative Meinungen gehört, die ich aber nicht nachvollziehen kann. Jedenfalls konnte ich damit auch komplexere Probleme wie motorisierte Throttles und Trimmung lösen. Im Moment arbeite ich an Force-Feedback, was ich auch mit SIOC steuern werde.

 

Fazit: Ich würde heute alles mit Opencockpits/SIOC machen. Oder dann andere Lösungen suchen.

 

2.
Nein. Du kannst natürlich die Flachbandkabel von Hispapanels aufbrezeln und in die Klemmleisten von OC-Prints schrauben. Aber das dürfte schon nur Probleme wegen der Schaltmassen geben. Bei Hispapanels sind alle Massen miteinander verbunden, also kein Multiplexing fürs Abtasten von Schaltern möglich.

 

3.
Wegen der Farben würde ich mir keine Sorgen machen. Die zumeist verwendeten RAL7011 und RAL7043 sind sehr ähnlich. Ich habe schon gehört, dass auch im richtigen Flieger Farbnuancen bestehen.

 

4.
Ja. Insbesondere, wenn Opencockpits-Geräte zum Einsatz kommen.

 

5.
Diese Erfahrung habe ich auch gemacht und praktisch alle mitgelieferten farbigen (Billig-) LEDs durch kräftige LEDs aus dem Elektronikhandel ersetzt.

 

6.
Ich denke, 0.22 ist völlig ausreichend für alles, ausser Motoren und zentrale Speisungskabel, z.B. ab separatem PC-Netzteil für 12 und 5 V.

 

7.
Gute Wahl. Innen matt, aussen Glanz.

 

Zwar kommen diese Antworten wieder aus der gleichen Ecke wie die bisherigen Beschreibungen. Ich hoffe dennoch, dass ich Dir etwas weiterhelfen konnte.

 

LG Urs

[Reto Stöckli]

Lieber Michael

 

Ich kann Urs bei allem beipflichten, habe aber noch eine dritte Lösung neben OC und Hispapanels, die ich grad teste: SISMO Soluciones. Das macht es natürlich für dich nicht einfacher, aber beachte folgende Erkenntnisse, die ich in den letzten 2-3 Monaten mit SISMO Soluciones gemacht habe:

• Die I/O Hardware ist etwas teurer als bei OpenCockpits
• Jedes Board ist eindeutig adressierbar. Dies ist ein Problem bei OpenCockpits. Die OC Boards sind per USB angeschlossen und wenn du z.B. drei Servo Cards hast, dann sehen für den Computer alle drei identisch aus. Die Serienummer ist auch überall die Gleiche. Du suchst die Karten über den USB Gerätebaum und pröbelst. Das geht meistens. Aber nach Betriebssystem-Updates oder Neustarts kann die Addressierung der USB Schnittstellen auch ändern. Auch Urs hatte meines Wissens damit seine Probleme.
• Verkabelung. Wie Urs schon geschrieben hat, OC Boards neigen zu einem Kabelsalat, auch beim Anschluss an den Computer. SISMO Soluciones arbeitet mit Ethernet, dh. ich muss eigentlich nur 1 Stromkabel und 1 Ethernet-Kabel durch das Cockpit führen.
• Ich arbeite auf Linux und habe das OC Protokoll selbst implementiert. Es ist für jede Karte anders und eher komplex aufgebaut. OpenCockpits hat das Protokoll auch nicht öffentlich gemacht. SISMO Soluciones hat ein sehr einfaches UDP Protokoll, das gut dokumentiert ist.
• SISMO Module sind sehr sorgfältig verarbeitet, alle Schalter etc. sind auf Prints montiert. Ich habe vor 2 Wochen den MCP und die beiden EFIS gekriegt und bin entzückt.
• Die Hintergrundbeleuchtung bei OC ist nicht sehr elegant und ungleichmässig. Man kann die Panels aber manuell mit besserer Beleuchtung ausstatten. Ich könnte dir dazu gerne einen Tipp geben, wenn du möchtest.
• Nachteil von SISMO Soluciones: sie haben keine Motorsteuerungs-Karten wie OpenCockpits. Weder für reguläre noch für Schrittmotoren.

Obwohl ich jetzt MCP, Pedestal und FWD Overhead mit OC gebaut habe, werde ich aufgrund der obigen Erkenntnisse wohl alles noch einmal von vorne beginnen mit SISMO Soluciones.

 

Noch meine Erfahrung zur Kabeldicke: Um LED's anzusteuern oder Schalter anzuhängen genügt 0.14 mm (maximaler Strom 3A). Wie von Urs dargelegt, die Speisung dann eher mit gröberem Durchmesser.

 

Auch Urs beipflichtend: die Farben unterscheiden sich im originalen Cockpit enorm. Ich habe eine B737-300 Shell, und viele der Elemente sind je nach Hersteller etwas anders bemalt. Dann ist das ganze Mobiliar drin in den 30 Betriebsjahren geschätzte 2-3 mal übermalt worden, mit der Konsequenz, dass der Farbton an jeder Ecke etwas anders aussieht. Man würde es nicht denken, aber auch in der Flugbranche gibt es gute und schlechte Handwerker und Maler

 

Ich wünsche dir ganz viel  Erfolg beim Projekt. Wenn ich im originalen Cockpit was nachmessen soll, lass es mich wissen.

Reto

 

[Reto Stöckli]

Hoi zäme

 

Hier aus aktuellem Anlass und für euch alle meine Bilder zur soeben fertiggestellten Minibar im B737 Cockpit draussen im Garten. Es ist mir leicht gefallen, dieses wichtige Element noch vor der Avionik und der Flugsteuerung zu priorisieren:

 

https://bluemarble.ch/wordpress/2021/03/10/where-actually-is-the-minibar-in-a-boeing-737-cockpit/

 

Apéros können ab sofort gebucht werden

Reto

[mip]

Lieber Urs, lieber Reto!

 

Vielen lieben Dank für eure Antworten, da bin ich schon einmal ein Stück weiter.

 

@Reto

Also dein B737 Cockpit ist ja grenzgenial! Und die Idee mit der Minibar greife ich auch gleich auf, ich habe ja auf der rechten Seite noch etwas Platz... 

Danke auch für den Tipp mit SISMO. Ich habe mal kurz drübergelesen und die Idee dahinter ist spitze. Da muss ich mich noch genauer einlesen. Aber gleich eine Frage: Die Programmierung läuft ja über SC-Pascal. Wie kommst du damit zurecht? Urs empfiehlt das ja im Zusammenhang mit den Panels von Hispapanels überhaupt nicht. Aber wie du schon gesagt hast, die Kosten werden auch etwas höher werden...

 

Mein Ziel ist es, im Frühsommer mit dem MIP anzufangen (also noch genügend Zeit zur Recherche). Vorher ist leider der Platz im Keller nicht vorhanden. Ich möchte aber bereits vorher soweit alles geplant haben.

 

Ich beschäftige mich gerade mit dem Ansatz Arduino - Mobiflight - FSUIPC. Der Vorteil ist, dass ich mit dieser Karte (fast) alles steuern kann (außer Potentiometers, wobei ich noch nicht weiß, ob ich das überhaupt benötigen werde). Weiters bekomme ich die Karte zum Teil sehr günstig gleich um die Ecke, ich erspare mir daher das Bestellen in Spanien mit den Transportkosten. Den Kabelsalat erspare ich mir dadurch natürlich nicht... Ich habe mir jetzt einmal überlegt, eine Arduino und ein paar LED's zu holen (Schalter habe ich noch ein paar zu Hause) und mittels einer Steckplatine einfach einmal ein Panel (d.h. ein Rotary Switch, ein tactile Switch und einen Annunciator) in groben Zügen zu bauen, damit ich verstehe wie die Elektronik dahinter funktioniert und wie ich das dann alles in die PMDG bringe.

 

Da gleich die Frage: welche LED wäre zu nehmen? Das Gehäuse sollte 3 mm sein und oben abgeflacht (für die Annunciators). Aber wie sieht es aus mit der Spannung/dem Strom, Abstrahlwinkel und Lichtstärke aus. Da gibt es ja eine Auswahl wie Sand am Meer...

 

Da nehme ich auch gleich das Angebot von Reto an wegen ein paar Tipps zur Hintergrundbeleuchtung der Panels an. Auf was ist hier zu achten? Eignen sich die LED-Streifen die OC/Hispapanels anbieten? Wie ordnet man die Streifen am Besten bei den Panels an? Ich weiß, Fragen über Fragen...

 

Danke schonmal wieder im Voraus für eure Hilfe.

 

LG

Michael

 

[Reto Stöckli]

Lieber Michael

 

Deine Fragen würden von der Komplexität her zu einer Skype-Sitzung einladen, aber ich hatte heute im Home Office schon 8 Stunden davon. Deshalb hier per Forum kurz das Wichtigste zu deiner Entscheidungshilfe:

 

SC-Pascal: ich verwende es nicht. Ich bin einer der wenigen Cockpit-Bauern, die auf Linux arbeitet und darum mit X-Plane. Keine der herkömmlichen Hardwarre-Anbindungen kommen für Linux in Frage und die wenigsten für X-Plane. Ich habe die gesamte Software vom Flugsimulator-Plugin bis zur Hardware-Anbindung selbst geschrieben. Dies hat den Vorteil, dass ich unabhängig bin von proprietärer Software wie SIOC. Es ist aus den Kommentaren in Foren ersichtlich, dass einige der Kollegen teilweise Wochen- bis Monatelang auf Updates der Hardware-Supplier warten, falls der Flieger, der Simulator, das Betriebssystem geändert hat. Ich habe momentan nur noch den NVIDIA-Treiber und X-Plane als proprietäre Software, die ich selbst nicht debuggen kann. Dieses Risiko ist für mich schon gross genug. Wobei weder das eine noch das andere wohl bald eingestampft werden wird (hoffentlich). Meine Software ist in C geschrieben und öffentlich. Aber sie ist nur mit X-Plane kompatibel, deshalb wohl keine Hilfe für dich?  https://github.com/retostockli/xpcockpit/wiki

 

Arduino. Sehr interessant. Ich hab grad damit angefangen und bin entzückt (4. Option für dich, und ein kleiner Beitrag zur allgemeinen Verwirrung). Der Arduino eignet sich meines Wissens für Dinge, die mit herkömmlichen I/O Boards nicht gehen. Er ist super stabil, und wie du sagst, günstig und einfach zu programmieren.

 

Ich habe von Urs die Idee bekommen, einen regulären Kompass mit zwei senkrecht gegeneinander montierten Spulen anzusteuern, um das Erdmagnetfeld auszutricksen. Dies verlangt, dass man je nach Flugrichtung des Flugzeugs das Magnetfeld über dem Kompass rotiert. Die Ansteuerung geschieht mit PWM Signalen und dafür hatte ich weder von OpenCockpits noch von SISMO eine Lösung. Gestern ist das werte Stück dann auch tatsächlich das erste Mal um die eigene Achse gedreht. Der Arduino ist bei mir mit einem Ethernet Shield erweitert, dh. ich steuere ihn mit einfachen UDP Paketen an. Das Bild hier zeigt den Prototypen. Arduinos könnten sich auch für Force-Feedback-Applikationen eignen, wo der eigentliche Force-Feedback Loop mit einer hohen Frequenz (> 500 hz) auf dem Mikrokontroller laufen sollte und nicht in der Kommunikation mit dem Computer (ansonsten produzierst du Schwingungen zwischen menschlichem Input und Motoren-Reaktion). Arduinos generell einzusetzen wäre warscheinlich auch möglich, aber da frage ich mich ob es Lösungen gibt, die 14 In/Outputs zu erweitern auf z.B. 200 In/Outputs? Gibt es das?

Mein Arduino hat übrigens 6 Analoge inputs, man kann also Potentiometer gut anschliessen, habe auch einen im Bild:

 

 

Zu der Hintergrundbeleuchtung. Ich habe einige Dinge ausprobiert mit einzelnen LEDs und breitem Abstrahlwinkel. Diese dann direkt auf das Plexiglas der OC Module geklebt oder gar reingebohrt. Das Resultat war immer eine recht punktuelle Ausleuchtung. Die Arbeit mit dem Verlöten einzelner LEDs war auch nicht grad entspannend, wenn ich das so sagen darf. Beim Overhead Panel habe ich dann die LED Stripes von OC genommen und sie zuerst auf das Plexiglas geklebt. Um eine einigermassen gleichmässige Ausleuchtung zu bekommen, hätte ich etwa doppelt so viele LED Stripes gebraucht, wie sie mir geliefert haben. Dann kam ich auf die Idee, die LED Stripes etwa 1 cm vom Plexiglas weg zu montieren. Ich habe dazu 3 oder 5 mm geschäumte PVC Platten als Montagebasis genommen. Die lassen sich einfach mit dem Teppichmesser zuschneiden. Ich habe dann die Form des Panels und der Schalter ausgeschnitten und die relativ leichte Platte mit den LED Streifen drauf in etwa 1 cm Distanz montiert. Sie ist nicht angeschraubt, sondern mit Heissleim an 2-3 Schalter drangeklebt, sie muss nur halten, hat keine mechanische Belastung. Läuft seit einem Jahr tiptopp im Overhead Panel. Dimmung passiert über einen regulären 12 V LED Dimmer über den Potentiometer auf dem Overhead Panel selbst:

 

 

Das Resultat von vorne ist meiner Erfahrung nach recht viel ausgeglichener und heller im Vergleich zum originalen Aufbau von OC:

 

 

Frag ruhig weiter, wir haben hier hoffentlich Zeit und Freude am Austausch. Im Beruf dauern die Projekte jedes Jahr weniger lang weil das Management auf Faster, Cheaper, Bigger setzt, aber beim Hobby kanns ruhig auch mal ohne Ende geplant werden. Ich meinerseits bin seit ca. 2006 dran mit dem Ziel, nie fertig zu werden. Die ersten 4 Jahre gingen drauf mit der Entwicklung der C-basierten Hardware - Anbindung und dann wurden zum Glück in meinen Leben auch noch 3 Kinder geboren und das Cockpit war fast vergessen. Mittlerweile stehen aber drei potentielle Copiloten parat auf ihren Einsatz (5, 9, 11).

 

Herzlich,

Reto

[Pancho33]

vor 4 Stunden schrieb Reto Stöckli:

Lieber Michael

 

Deine Fragen würden von der Komplexität her zu einer Skype-Sitzung einladen, aber ich hatte heute im Home Office schon 8 Stunden davon. Deshalb hier per Forum kurz das Wichtigste zu deiner Entscheidungshilfe:

 

SC-Pascal: ich verwende es nicht. Ich bin einer der wenigen Cockpit-Bauern, die auf Linux arbeitet und darum mit X-Plane. Keine der herkömmlichen Hardwarre-Anbindungen kommen für Linux in Frage und die wenigsten für X-Plane. Ich habe die gesamte Software vom Flugsimulator-Plugin bis zur Hardware-Anbindung selbst geschrieben. Dies hat den Vorteil, dass ich unabhängig bin von proprietärer Software wie SIOC. Es ist aus den Kommentaren in Foren ersichtlich, dass einige der Kollegen teilweise Wochen- bis Monatelang auf Updates der Hardware-Supplier warten, falls der Flieger, der Simulator, das Betriebssystem geändert hat. Ich habe momentan nur noch den NVIDIA-Treiber und X-Plane als proprietäre Software, die ich selbst nicht debuggen kann. Dieses Risiko ist für mich schon gross genug. Wobei weder das eine noch das andere wohl bald eingestampft werden wird (hoffentlich). Meine Software ist in C geschrieben und öffentlich. Aber sie ist nur mit X-Plane kompatibel, deshalb wohl keine Hilfe für dich?  https://github.com/retostockli/xpcockpit/wiki

 

Arduino. Sehr interessant. Ich hab grad damit angefangen und bin entzückt (4. Option für dich, und ein kleiner Beitrag zur allgemeinen Verwirrung). Der Arduino eignet sich meines Wissens für Dinge, die mit herkömmlichen I/O Boards nicht gehen. Er ist super stabil, und wie du sagst, günstig und einfach zu programmieren.

 

Ich habe von Urs die Idee bekommen, einen regulären Kompass mit zwei senkrecht gegeneinander montierten Spulen anzusteuern, um das Erdmagnetfeld auszutricksen. Dies verlangt, dass man je nach Flugrichtung des Flugzeugs das Magnetfeld über dem Kompass rotiert. Die Ansteuerung geschieht mit PWM Signalen und dafür hatte ich weder von OpenCockpits noch von SISMO eine Lösung. Gestern ist das werte Stück dann auch tatsächlich das erste Mal um die eigene Achse gedreht. Der Arduino ist bei mir mit einem Ethernet Shield erweitert, dh. ich steuere ihn mit einfachen UDP Paketen an. Das Bild hier zeigt den Prototypen. Arduinos könnten sich auch für Force-Feedback-Applikationen eignen, wo der eigentliche Force-Feedback Loop mit einer hohen Frequenz (> 500 hz) auf dem Mikrokontroller laufen sollte und nicht in der Kommunikation mit dem Computer (ansonsten produzierst du Schwingungen zwischen menschlichem Input und Motoren-Reaktion). Arduinos generell einzusetzen wäre warscheinlich auch möglich, aber da frage ich mich ob es Lösungen gibt, die 14 In/Outputs zu erweitern auf z.B. 200 In/Outputs? Gibt es das?

Mein Arduino hat übrigens 6 Analoge inputs, man kann also Potentiometer gut anschliessen, habe auch einen im Bild:

 

 

Zu der Hintergrundbeleuchtung. Ich habe einige Dinge ausprobiert mit einzelnen LEDs und breitem Abstrahlwinkel. Diese dann direkt auf das Plexiglas der OC Module geklebt oder gar reingebohrt. Das Resultat war immer eine recht punktuelle Ausleuchtung. Die Arbeit mit dem Verlöten einzelner LEDs war auch nicht grad entspannend, wenn ich das so sagen darf. Beim Overhead Panel habe ich dann die LED Stripes von OC genommen und sie zuerst auf das Plexiglas geklebt. Um eine einigermassen gleichmässige Ausleuchtung zu bekommen, hätte ich etwa doppelt so viele LED Stripes gebraucht, wie sie mir geliefert haben. Dann kam ich auf die Idee, die LED Stripes etwa 1 cm vom Plexiglas weg zu montieren. Ich habe dazu 3 oder 5 mm geschäumte PVC Platten als Montagebasis genommen. Die lassen sich einfach mit dem Teppichmesser zuschneiden. Ich habe dann die Form des Panels und der Schalter ausgeschnitten und die relativ leichte Platte mit den LED Streifen drauf in etwa 1 cm Distanz montiert. Sie ist nicht angeschraubt, sondern mit Heissleim an 2-3 Schalter drangeklebt, sie muss nur halten, hat keine mechanische Belastung. Läuft seit einem Jahr tiptopp im Overhead Panel. Dimmung passiert über einen regulären 12 V LED Dimmer über den Potentiometer auf dem Overhead Panel selbst:

 

 

Das Resultat von vorne ist meiner Erfahrung nach recht viel ausgeglichener und heller im Vergleich zum originalen Aufbau von OC:

 

 

Frag ruhig weiter, wir haben hier hoffentlich Zeit und Freude am Austausch. Im Beruf dauern die Projekte jedes Jahr weniger lang weil das Management auf Faster, Cheaper, Bigger setzt, aber beim Hobby kanns ruhig auch mal ohne Ende geplant werden. Ich meinerseits bin seit ca. 2006 dran mit dem Ziel, nie fertig zu werden. Die ersten 4 Jahre gingen drauf mit der Entwicklung der C-basierten Hardware - Anbindung und dann wurden zum Glück in meinen Leben auch noch 3 Kinder geboren und das Cockpit war fast vergessen. Mittlerweile stehen aber drei potentielle Copiloten parat auf ihren Einsatz (5, 9, 11).

 

Herzlich,

Reto

 

Lieber Reto, lieber Urs und lieber Michael....

ich bin ein grosser "Mitleser" eurer tollen  homecockpit Geschichten und auch meine Pläne werden dadurch immer mehr bestärkt, sich an den Bau eines Cockpits zu wagen... habe auch viel Zeit hier und ich kann ja nicht den ganzen Tag nur Elche beobachten ...

Grüße

Dieter aus Schweden

[Pancho33]

Habe mir in der Zwischenzeit auch so ein Starter Kit mit einem Arduino Mega2560 besorgt, um mich mit der gesamten Elektronic mehr zu

befassen. Arduino in Verbindung mit Mobiflight finde ich als Laie eine interessante Sache. Auch die youtube Videos von Urs in Bezug auf den Arduino sind sehr lehr- und hilfreich !

Liebe Grüße

Dieter

[Alpin-Flier]

Hoi zäme

 

Sehr schön, dass es hier wieder eine interessante Diskussion um den Cockpit-Bau gibt. Da mache ich gerne mit

 

Im Zusammenhang mit meinem geplanten Force-Feedback habe ich mir Rasperry und Arduino etwas näher angeschaut und auch überlegt, ob ich damit meine Hispapanels-Elektronik ersetzen könnte. Ich habe schnell wieder aufgehört, darüber nachzudenken. Nur schon für die relativ wenigen Module mit Direktanschluss in MCP, MIP und Teile des Pedestal brauchte ich rund 240 Eingänge (Schalter) und rund 120 Ausgänge (LEDs). Dazu käme noch das Overhead plus restliches Pedestal mit noch höheren Anschlusszahlen. Das ist IMHO mit Arduino bzw. Rasperry mit vernünftigem Aufwand nicht zu schaffen bzw. recht kompliziert. Zum Vergleich mein Simio-Aufbau: Ich verwende nebst dem Display-Board zwei Inputboards mit je 64 Eingängen, drei Gemischtboards mit je 32 Ein- und 32 Ausgängen sowie das Masterboard mit nochmals je 16 Ein- und Ausgängen. Die meisten Anschlüsse sind belegt. Dank Flachbandkabeln hält sich der Kaberlverhau zum Glück in Grenzen. Hier der Aufbau, noch ohne Kabel zu den Modulen. Oben links die nicht im Bus eingebundene Servokarte, unten rechts der Master:

 

 

 

 

Bezüglich SC-Pascal habe ich mich auf die fehlende Unterstützung bei Hispapanels bezogen. Nun habe ich mir auch die Sismo-Homepage angeschaut und gesehen, dass die tatsächlich auch SC-Pascal verwenden, welches offenbar mehr kann als meine Version. Daraus ziehe ich den Schluss, dass der SW-Entwickler sich offenbar vor Jahren von Hispapanels abgesetzt und sich bei Sismo Soluciones engagiert hat. Simio ==> Sismo. Oder so ähnlich... Allerdings finde ich die Hardware von Sismo sehr teuer. Ich werde mich mal drum kümmern, ob ich zumindest das aktuelle Sismo_SC-Pascal auch auf meiner HW verwenden könnte. Nur schon wegen dem bei mir fehlenden, spontanen Read_Input-Befehl, der für die Initialisierung/Synchronisierung des Cockpits so nötig wäre...

 

@Dieter: Ich habe nie Videos bezüglich Arduino publiziert. Ich habe mir zwar vor kurzem einen Rasperry_3B beschafft, aber wieder zur Seite gelegt. Den Force-Feedback werde ich nun mit einer Motorcard von Opencockpits realisieren. Dazu muss ich nur mein SIOC-Script erweitern und keine neue SW-Plattform einführen.

 

LG Urs

Bearbeitet 13. März 2021 von Alpin-Flier
Link korrigiert

[EdeBanatzke]

Hallo Leute, 

Ich lese hier mit Bewunderung und grossem Respekt schon lange mit.

Auch ich möchte mich nun hier kurz vorstellen.

Mein Name ist Gerhard, alle nennen mich aber Piki, so soll es dann auch hier sein.
Ich lebe in Deutschland bei Hannover und bin seid neustem Rentner, aber nur dem Alter nach.

 

 

Nachdem ich eigentlich schon immer mit dem FS rumgespielt habe und seid den Neunzigern
 regelmäßig 1x pro Jahr bei der LH im FullFlight-Simulator das Erlebniss hatte dort rumfliegen zu können, wurde mir das 2017 zu teuer.
Also reifte die Entscheidung einen eigenes Homecockpit zu realisieren.
Da meine Frau meine Macken toleriert, Gott sei gedankt, und ich kein Mensch langer Planung bin, ran ans Projekt.

Inzwischen wurde das Ding 3 x umgebaut.

1) P3D und PMDG bzw. iFly 737NG. War mir nicht genug Systemtiefe was den Zugriff auf die Flugzeugvariablen betrifft.
2) Mechanischer Aufbau Quick & Dirty. Meine Ungeduld.

Nun 3) Vernünftiger mechanischer Aufbau, wechsel zu XPlane und Zibo 737x.

Das MCP und 1 Efis habe ich von OC, wie hier schon mehrfach gesagt USB, Support, usw. nicht meinen Vorstellungen entsprechend.

Alles andere daraufhin selbstgebaut mit Arduino "kompatiblem" ESP8266, ESP32, Teensy und selbst in C programmiert.

Etliche Raspis sind z.B. in den beiden FMC-CDUs und für die Darstellung der sekundären Bildschirme verbaut. Insgesamt 9 Monitore wuden verbaut.

Mein Ansatz: Jede funktionale Einheit hat ihren eigenen Prozessor und kommuniziert mit Xplane/737 die Zustände per USB oder Wlan.
Dadurch komme ich mit einem einzigen Powerrechner für die komplette Simulation aus, alles andere machen die einzelnen Stationen
 selbst und kommunzieren es nur bzw. stellen(steuern) die eigenen Zustände dar. (motoren,LEDs, Servos usw.).
 
Die "Armaturenbretter" habe ich alle von https://www.cockpitsimparts.co.uk/,. Super Qualität, passt alles. RAL 7011

Schalter usw. AliExpress,Amazon, und diverse Quellen.

Nunmehr sind auch 2 3D-Drucker im Einsatz, 1 Anet A8 20x20 cm, und ein Tronxy umgebaut auf 35x35cm, beide haben ihr Geld mehr als verdient.

Als Konstuktionsoftware nutze ich Fusion360, kostenfrei für den Hobbybereich!

Alles funkioniert wie im FCOM der 737 beschrieben, ok, die Temperaturen im Cockpit und in der Kabine können auch Dummy sein. Macht keinen Sinn.

Den Throttlequadranten habe ich nunmehr 2 mal gebaut und bin mit der Haptik nicht zufrieden, wird er halt ein drittesmal gebaut,
 diesmal nicht mit Ruschkupplungen, sonder mit Planatengetriebe. Mal sehen, Frust gehört dazu, sonst sollte man solch ein Projekt garnicht erst angehen.
 Die Thottles bewegen sich, Parkbrake wird ausgelöst und Speedbrake geht nach WoW auf full detend. Flaps mit einem Widerstandsnetzwerk auf einen Analogpin gelegt (9 Schaltzustände, nur 3 Kabel).
 
Den Kompass habe ich mit einen Schrittmotor, einem AS5048b statt Poti und einem ESP8266 realisiert, funktioniert gradgenau in Echtzeit.
Die übrigen Analoginstrumente sind mit X27-168 Schrittmotoren für Analoginstrumente aus dem KFZ. Bereich (10st. 18€) und jeweils 1 x Wemos D1 gebaut und funktionieren top.

Yoke mit Force Feedback für die Trimmung funktioniert auch schon und wird als nächstes Erweitert um im CMD Mode auf den Yoke selbst zu bewegen.

Mein Ziel ist es allen Stationen nur die Spannungsversorgung zuzuführen und den Rest über Wlan/Lan abzuhandeln.

@ Reto: Mein Traum ist ein vernünftiges Protokoll über alle Hardwareschichten, welches open Source ist und man alle Hard/Software miteinnander kombinieren kann, ob selbstbebaut oder fertig zu kaufen.
nach dem PUB/SUB System Beispiel MTTQ. Aber darüber können, wenn Du möchtest, separat diskutieren.

Deine Software werde ich mir in der nächsten Woche ausfühlich reinziehen.

So, Alles ziemlich zusammenhanglos rausgeplaudert, aber wenn ich mich mit Rat und Ideen einbringen kann, so mache ich das Gerne.
Sollte ich helfen können bezüglich Lösungsansätzen, so gebe ich meine gerne weiter. Multiplexer, I2C-Dimmcontroller, AS5048-programmierung, usw.

Bilder hier

Bilder hier: https://drive.google.com/drive/folders/1XlkiIvIdxpUG0pldtOVbfr_zE8J7kgFx

Gruss aus Hannover und bleibt gesund

Piki

 

Bearbeitet 12. März 2021 von EdeBanatzke

[Reto Stöckli]

Eine solch schöne Diskussion!

Ich melde mich wieder

Reto

[Pancho33]

Hallo zusammen !!

Lieber Urs das ist mir gerade richtig peinlich !!

Habe die Videos des "Hobbyelektronikers" mit dir in Verbindung gebracht, da ich seine Stimme mit dir assoziiert habe !! Sorry ! Ansonsten folge ich natürlich interessiert dem Geschehen in diesem thread !

 

Grüße

Dieter

[Pancho33]

Hej Piki !

Erstmal möchte ich dich hier bei uns begrüßen und dir meinen vollen Respekt für das zukommen lassen, was du

auf die Beine gestellt hast.  Sieht einfach nur beeindruckend aus. Wie das homecockpit von Urs

auch. Davon kann ich nur träumen.

 

Liebe Grüße

Dieter

[EdeBanatzke]

vor 15 Stunden schrieb Pancho33:

Hej Piki !

Erstmal möchte ich dich hier bei uns begrüßen und dir meinen vollen Respekt für das zukommen lassen, was du

auf die Beine gestellt hast.  Sieht einfach nur beeindruckend aus. Wie das homecockpit von Urs

auch. Davon kann ich nur träumen.

 

Liebe Grüße

Dieter

Danke für dein Lob!

Der Weg ist das Ziel.

Wenn ich mit meinem bescheidenen Wissen helfen kann, so tue ich das gerne.

LG

Piki

[Reto Stöckli]

Hoi Piki

 

Dein Set-Up sieht äusserst elegant aus und wir sind mit X-Plane und ZIBO 737 etwa auf der gleichen Flughöhe. Ich gehe aber davon aus, dass du auf Windows arbeitest (ich versuch die ganze Sauce auf Linux zu realisieren). Die Idee mit einem einzelnen Haupt-Rechner habe ich schon von Urs bekommen und sie scheint mir zielführend, weil man dann nur ein einzelner Flugsimulator "a jour" halten muss. Die heutigen Grafikkarten sollten zudem auch 3-5 externe Visuals mit vernünftiger Framerate ansteuern können.

 

Es wäre mir eine Ehre, wenn du mein Protokoll und das Plugin mal ausprobieren könntest. Ich habe es tatsächlich so geschrieben, dass es mit einem Minimum an Network Traffic auskommt. Dh. jeder Client "abonniert" die für ihn notwendigen Datarefs bei X-Plane. Dh. kein mühsames Editieren von FSUIPC Offsets etc. Der Client sagt dem Flugsimulator auch, in welcher Präzision die Dataref Inhalte gesendet werden sollen. Dh. bei floating point values kannst du entscheiden, ob du für die Flughöhe z.B. nur alle 10 Fuss oder allenfalls doch pro 0.01 Fuss ein Update haben möchtest. Das hat meiner Erfahrung nach einen signifikanten Effekt auf die Performance des ganzen Systems. Die Daten werden auch im originalen X-Plane Datenformat übertragen, es gibt also alle Datentypen 1:1 in den Clients wie im Flugsimulator. Man kann von den Array-Datentypen auch nur einzelne Elemente "abonnieren". Protokoll läuft stabil bei mir auch auf recht langen Flügen. Soweit so gut. Jetzt aber zu den Löchern im Schweizer Käse: der Windows-Support ist noch dürftig. Ich habe selbst keine Windows-Entwicklerumgebung. Ich habe das Plugin (xpserver) und die clients (xpclient, xpusb, xpopengc) mal mit minGW auf Windows kompilieren können und es läuft auch, aber irgendwie fühlt sich der Code noch nicht so Windows-freundlich an. Hast du hier allenfalls mehr Erfahrung?

 

Jetzt noch eine Frage an dich: die Idee mit einem Rasperry Pi pro MIP Monitor ist verlockend. Welche Glass Cockpit Software verwendest du? Bei mir wären auf dem Rasperry sicher mal X11 notwendig und 1 GB RAM für die Anwendung selbst. OpenGC benötigt etwa 5-10% CPU einer single Core auf einem modernen Rechner. Läuft das auf einem Rasperry PI dann sinnvoll? Hast du Erfahrung damit?

Noch eine weitere Frage: hättest du die Spezifikationen deiner Monitore, die du im MIP verbaut hast?

 

Deine Idee mit WLAN ist auch interessant. Ich hätte jetzt ein Ethernet-Kabel im Flieger verlegt. Läuft die WLAN-Sache genug stabil und ohne grosse Delays z.B. bei den Glass-Cockpit-Anzeigen?

 

Dies vorerst mal als Anfangs-Fragestunde meinerseits. Falls es zu detailliert würde, können wir uns auch noch privat austauschen. Obwohl vielleicht einige Anwärter für Home Cockpits auch gerne mithören.

 

Reto

[Reto Stöckli]

On 3/12/2021 at 9:47 AM, Alpin-Flier said:

 

@Dieter: Ich habe nie Videos bezüglich Arduino publiziert. Ich habe mir zwar vor kurzem einen Rasperry_3B beschafft, aber wieder zur Seite gelegt. Den Force-Feedback werde ich nun mit einer Motorcard von Opencockpits realisieren. Dazu muss ich nur mein SIOC-Script erweitern und keine neue SW-Plattform einführen.

 

LG Urs

 

 

Lieber Urs

 

Ich hatte mir damals auch überlegt, mittels einer USB DCMotor Card von OC den Force Feedback zu realisieren. Ian von BFF hat mir aber dann vorgerechnet, dass dies nicht geht, weil der nicht-lineare Feedback-Loop über USB und SIOC oder ein anderes Interface zu langsam sei und unerwünschte Schwingungen zwischen Yoke Input und Motoren-Feedback auslösen würde. Er schlägt > 500 hz als Feedback Loop vor, und das ist seiner Meinung nach nur über einen Mikrokontroller realisierbar, der direkt mit den Motoren verknüpft ist und die nicht-lineare Feedback-Funktion (in Abhängigkeit der Aerodynamik etc.) drin hat. Ich hab es dann aber selbst nicht ausprobiert, und von Ian mal eine 1-Motor-Steuerung gekauft. Leider ist sein Protokoll nicht öffentlich und ich hatte keine Chance, das auf Linux umzusetzen. Dh. diese Steuerung liegt bei mir jetzt einfach mal rum. Ich denke drum grad an eine Lösung mit Arduino nach, würde dich aber gerne fragen, ob du dir die Gedanken von Ian auch schon gemacht hast wegen der Frequenz des Feedback-Loops?

 

Herzlich,

Reto

 

PS: Gestern war in LSZH auf Vatsim die Hölle los. Es gab so einen jährlichen Event mit voller ATC Belegung und entsprechend vielen Fliegern. Die Wartezeit lag so bei 45' zwischen Aufruf zu "Ready for Push & Start" und dem ok dazu von LSZH Ground

 

[EdeBanatzke]

vor 5 Stunden schrieb Reto Stöckli:

Hoi Piki

 

Dein Set-Up sieht äusserst elegant aus und wir sind mit X-Plane und ZIBO 737 etwa auf der gleichen Flughöhe. Ich gehe aber davon aus, dass du auf Windows arbeitest (ich versuch die ganze Sauce auf Linux zu realisieren). Die Idee mit einem einzelnen Haupt-Rechner habe ich schon von Urs bekommen und sie scheint mir zielführend, weil man dann nur ein einzelner Flugsimulator "a jour" halten muss. Die heutigen Grafikkarten sollten zudem auch 3-5 externe Visuals mit vernünftiger Framerate ansteuern können.

 

Es wäre mir eine Ehre, wenn du mein Protokoll und das Plugin mal ausprobieren könntest. Ich habe es tatsächlich so geschrieben, dass es mit einem Minimum an Network Traffic auskommt. Dh. jeder Client "abonniert" die für ihn notwendigen Datarefs bei X-Plane. Dh. kein mühsames Editieren von FSUIPC Offsets etc. Der Client sagt dem Flugsimulator auch, in welcher Präzision die Dataref Inhalte gesendet werden sollen. Dh. bei floating point values kannst du entscheiden, ob du für die Flughöhe z.B. nur alle 10 Fuss oder allenfalls doch pro 0.01 Fuss ein Update haben möchtest. Das hat meiner Erfahrung nach einen signifikanten Effekt auf die Performance des ganzen Systems. Die Daten werden auch im originalen X-Plane Datenformat übertragen, es gibt also alle Datentypen 1:1 in den Clients wie im Flugsimulator. Man kann von den Array-Datentypen auch nur einzelne Elemente "abonnieren". Protokoll läuft stabil bei mir auch auf recht langen Flügen. Soweit so gut. Jetzt aber zu den Löchern im Schweizer Käse: der Windows-Support ist noch dürftig. Ich habe selbst keine Windows-Entwicklerumgebung. Ich habe das Plugin (xpserver) und die clients (xpclient, xpusb, xpopengc) mal mit minGW auf Windows kompilieren können und es läuft auch, aber irgendwie fühlt sich der Code noch nicht so Windows-freundlich an. Hast du hier allenfalls mehr Erfahrung?

 

Jetzt noch eine Frage an dich: die Idee mit einem Rasperry Pi pro MIP Monitor ist verlockend. Welche Glass Cockpit Software verwendest du? Bei mir wären auf dem Rasperry sicher mal X11 notwendig und 1 GB RAM für die Anwendung selbst. OpenGC benötigt etwa 5-10% CPU einer single Core auf einem modernen Rechner. Läuft das auf einem Rasperry PI dann sinnvoll? Hast du Erfahrung damit?

Noch eine weitere Frage: hättest du die Spezifikationen deiner Monitore, die du im MIP verbaut hast?

 

Deine Idee mit WLAN ist auch interessant. Ich hätte jetzt ein Ethernet-Kabel im Flieger verlegt. Läuft die WLAN-Sache genug stabil und ohne grosse Delays z.B. bei den Glass-Cockpit-Anzeigen?

 

Dies vorerst mal als Anfangs-Fragestunde meinerseits. Falls es zu detailliert würde, können wir uns auch noch privat austauschen. Obwohl vielleicht einige Anwärter für Home Cockpits auch gerne mithören.

 

Reto

Hallo Reto,
erstmal danke für dein Feedback.

Ich schreibe Dir mal quick & dity mein Setup runter.

Hauptrechner: 32Gb Ram, Gforce 1080ti, ssd, AMD Ryzen  3600. that´s it.

Bildschirme: 
Draussen: 3 x 43" TV-Screens, je direkt an der 1080ti zu einem virtuellem Bildschirm zusammengefasst. Auflösung zusammen 5760 X 1280.

MIP: 2 x 19" (left & Right DU´s) 1 x 15"(Upper DU), 1x 10 (Lower DU) " je 2 per hdmi an zwei Raspberry 4 8gb mit 64bit Buster beta.

FMC-CDU: 2 x 5" mit  je vga karte an 2 Raspi zero w.

Sound: 40€ KFZ  Verstärker für die Normalen Lautsprecher sowie je einem BassShaker in den Sitzen fürs popometer.

Software:
Windows 10 pro
Xplane 11, Zibo 737x, EXTPlane-plugin, Teensy-Plugin, Dataref-Editor, ocusbmapper plugin für 1 Efis & MCP von OC.

MIP: Glass Cockpit Software: ZHSI auf Raspberry 4 8 GB, läuft auf Linux/Java. über Extplane-Plugin.

FMC-CDU: Open Source Platine, und Software von https://easyeda.com/dotsha747/737fmccdu-v3 anbindung über Extplane-Plugin.
Hier habe ich noch 3 Platinen neu und unbestückt übrig, gebe ich für 10€/stk. plus Porto gerne ab.

Overhead: 2 x Teensy 3.5 mit diversen I2C-Multiplexern, 1 Teensy für 127 InputPorts für Schalter + Servos für Magneto-Rückstellung, 1 Teensy für 127 Outputports für LED (Annunciator)

Pedestrial: 1 x Teensy mit I2C-Multlexer für alles, incl. Frequenzanzeigen und Encodern.

Throttlequadrant: 1 x Teensy mit L298N Treibern für 4 Motoren, 2xThrottle, 1 x Speedbrake detend, 1x Trimmräder, plus 1 x servo Parkbrakerelease

Posititionsfestellung aller drehbaren Achsen im Setup über AMS as5048b 360grad Hallsensoren, da mir Potis zu ungenau sind.

Backlights: 1 x Teensy mit PCA9685 16-Kanal 12-Bit PWM Servomotortreiber I2C Modul für die unabhängige Steuerung der verschiedenen Backlights auf LED-Streifen.

Yoke: 1 x Teensy mit Motorsteuerung für Trimmen des Yokes in Elevator und Aileron-richtung. bin grad am realisieren des Feedbacks wenn im CMD-Mode geflogen wird. Zeitproblem.

Alle 10 Analoginstrumente: je 1 x ESP 8266 (Wemos D1) mit Steppermotor X27-168 direkt per Wlan und extplane. Flap und Cabin-Alt per doppelmotor und ESP8266.

Wlan: alte 7390 Fritzbox tut es allemal, Bandbreite ist kein Problem, da die Fritzbox exklusiv für den Flusi ein eigenes Netz bildet.

Die Teensy´s sind per USB2 an den Hauptrechner angeschlossen und werden vom Xplane per eigenem Plugin versorgt (openSource -> Teensyduino)  

Alle ESP Wlan-Module sind übers Wlan upgradfähig, keine basteln.

1 altes PC-Netzteil realisiert die komplette Spannungsversorgung im Cockpit mit 12V und 5V.

So das ist in groben Zügen mein Setup.

Motorensteuerung war für mich mit den L298N Treibern kein Problem.

Hab hier noch ne OC Motorcard und Dimcontrolcard unbenutzt rumliegen.

Ich bin übrigens kein FPS-Junki, solange ich flüssig fliegen und landen kann, sind mir die FPS wurscht. Das langsamste Teil bin sowiso ich.

Abstürze hab ich übrigens auch nach Stunden nicht:

So, nun zum Protokoll:

Der MSFS 2020 sieht ja optisch schon verführerisch aus und läuft auf meinem Setup richtig gut, Aber.

Die Airliner sind bis jetzt reines Spielzeug, das wird sich m. Meinung nach auch in den nächsten 2 Jahren nicht ändern.
Für meinen Anspruch an Systemtiefe an das Flugzeug (HC-Anbindung).

Seis Drum, ich möchte mein Setup so vorbereiten, das ich wenn ich will ohne großen Aufwand den Sim wechseln kann und wieder zurück.

Hier schwebt mir ein Protokoll vor, mit dem ich an den Arduinos, Raspis, usw. keine Hand anlegen muss. Die kommunizieren mit einem Serverprozess, der wiederum die Aufrufe empfängt und je nach laufendem Sim in die richtigen Variablen und Commands hi- und her übersetzt.

Ich werde mir dein Protokoll gerne ansehen und mal versuchen mit einem ESP über dein Protokoll Funktionen zu realisieren.
Ist dein Xplane-Plugin auch für Windows  vorhanden. hab noch nicht nachgesehen.

Ich würde mich  mit Dir, Reto gerne mal über meine Vorstellungen evtl. telf. austauschen. Hier dauert mir die schreiberei zu lange, sollte was sinnvolles aus diesem Gespräch werden so soll es natürlich auch hier diskutiert werden.

 

 
LG Piki

[Alpin-Flier]

vor 7 Stunden schrieb Reto Stöckli:

Ich hatte mir damals auch überlegt, mittels einer USB DCMotor Card von OC den Force Feedback zu realisieren. Ian von BFF hat mir aber dann vorgerechnet, dass dies nicht geht, weil der nicht-lineare Feedback-Loop über USB und SIOC oder ein anderes Interface zu langsam sei und unerwünschte Schwingungen zwischen Yoke Input und Motoren-Feedback auslösen würde.

 

Ich halte mich an den Grundsatz: Traue keiner Studie, die Du nicht selbst gefäscht hast . Im Ernst, wenn ich mich nur aufs Internet verlassen hätte, wären bei mir jetzt auch mehrere PCs verbaut. Die Motorregelung über SIOC ist kein Neuland für mich. Beim Throttle und der Trimmung funktioniert das schon sehr gut. Ich kann wahrscheinlich dieselben Routinen auch für den Force-Feedback verwenden. Das sind nur wenige Scriptzeilen pro Motor. Mein Trick: nicht die Aenderungen (event-gesteuert wie sonst üblich) als Trigger für den Regelkreis verwenden, sondern einen Timer-gesteuerten Zyklus

- Regelkreis wird linear und ist trotzdem noch schnell genug

- geringe Programmbelastung

Ob das schliesslich auch für Force-Feedback klappt, wird sich weisen. Zumindest bin ich mit der Hardware durch. Hier ein paar Bilder dazu:

 

Uebersicht mit Motor/Seilantrieb/Gestänge für Höhenruder im Vordergrund und Motor/Seilantrieb für Querruder im Hintergrund:

 

Wegen der geringen Bauhöhe unter der Bodenplatte und dem kurzen Weg der Höhenruderanlenkung brauchte es eine Uebersetzung:

 

Auch die Elektronik ist schon bereit. Da das Opencockpits-Board Motorströme von max. 1A erlaubt, habe ich zwei starke, gekühlte Endstufen mit max. 3.6A Spitzenstrom nachgeschaltet. Das müsste wohl reichen für Zentrierung bzw. spürbare Kräfte:

 

Es war übrigens nicht gerade einfach, Motoren und Gestänge nachträglich einzubauen. Dank der Motion konnte ich die Plattform aber einfach auf 30 cm anheben und darunter kriechen. Ein zugegebenermassen etwas mulmiges Gefühl... aber ich lebe noch . Nun geht's an die SW.

 

LG Urs

[Pancho33]

Hallo Piki, Reto und Urs !

 

Schreibt weiter so eure Erfahrungen und Ideen hier nieder!!! Ich lese immer mit und kann dabei viel lernen !

Danke

 

Liebe Grüsse

Dieter

[mip]

Hallo!

 

Zunächst vielen Dank für eure Beiträge und Hilfestellungen, da bin ich schon einmal ein Stück weiter.

Ich habe mir vor ein paar Tagen ein Arduino-Board (oder besser gesagt einen Nachbau, kostet heiße 15 Euro) und ein paar Komponenten (Steckplatine, LED's, Kabeln etc.) geholt. Damit habe ich jetzt ein paar Funktionen ausprobiert und ich muss sagen, dass mit Hilfe von Mobiflight das sehr gut funktioniert. Parking-Brake LED hat auf Anhieb funktioniert, bei den Schaltern, Rotary Switches und Encodern musste ich ein bisschen probieren, hat aber dann auch alles geklappt. Mein Plan ist es jetzt einmal, mit Hilfe von Arduino/Mobiflight das MIP zu bauen und zu probieren, wie stabil das System dann ist, wenn es "länger" arbeiten muss. Im MIP ist eigentlich fast alles verbaut, was man später für Pedestal und Overhead braucht, somit aus meiner Sicht ein guter Test. Sollte das nicht funktionieren, dann habe ich "nur" die Arduinos umsonst gekauft (bei 3 oder 4 Boards ist das aber verkraftbar).

 

Bei den Encodern habe ich aber auch wieder was gelernt: ich habe Encoders von Hispapanels zu Hause, hier ist mir aufgefallen, dass man 4x drehen muss, damit sich im FSX etwas tut. Ich habe das mit dem HDG-Selector vom MCP getestet und da dreht man schon eine Weile... Es gibt anscheinend Encoders mit verschiedenen "Rastungen" (4:1, 2:1 oder 1:1). Daher meine Frage: welche habt ihr da verbaut? Oder generell die Frage: woher habt ihr die ganzen Schalter, Encoders etc? Hispapanels/OC oder doch vom Elektromarkt um die Ecke?

 

Danke (wiedereinmal) vorab für eure Antworten.

LG

Michael

[EdeBanatzke]

Hallo Michael,

 

Wo kaufe ich? Bei AliExpress sind die Preise unschlagbar, dauert aber 4-6Wochen. Bei Amazon wenn's schnell gehen muss, musst aber sehr genau auf die Lieferzeit achten, sonst wieder aus China.

 

Encoder? Meine Kenntniss nach sind die Standard encoder alle gleich, nur die Software kommt nicht hinterher wenn du zu schnell drehst.

Dazu musst du Interrupts benutzen, weiss aber nicht ob Mobiflight das unterstützt, da ich alles selbst programmiere und mit xplane arbeite.

Hoffe konnte helfen.

 

Gruß

Piki

[Reto Stöckli]

10 hours ago, mip said:

Hallo!

 

Zunächst vielen Dank für eure Beiträge und Hilfestellungen, da bin ich schon einmal ein Stück weiter.

Ich habe mir vor ein paar Tagen ein Arduino-Board (oder besser gesagt einen Nachbau, kostet heiße 15 Euro) und ein paar Komponenten (Steckplatine, LED's, Kabeln etc.) geholt. Damit habe ich jetzt ein paar Funktionen ausprobiert und ich muss sagen, dass mit Hilfe von Mobiflight das sehr gut funktioniert. Parking-Brake LED hat auf Anhieb funktioniert, bei den Schaltern, Rotary Switches und Encodern musste ich ein bisschen probieren, hat aber dann auch alles geklappt. Mein Plan ist es jetzt einmal, mit Hilfe von Arduino/Mobiflight das MIP zu bauen und zu probieren, wie stabil das System dann ist, wenn es "länger" arbeiten muss. Im MIP ist eigentlich fast alles verbaut, was man später für Pedestal und Overhead braucht, somit aus meiner Sicht ein guter Test. Sollte das nicht funktionieren, dann habe ich "nur" die Arduinos umsonst gekauft (bei 3 oder 4 Boards ist das aber verkraftbar).

 

Bei den Encodern habe ich aber auch wieder was gelernt: ich habe Encoders von Hispapanels zu Hause, hier ist mir aufgefallen, dass man 4x drehen muss, damit sich im FSX etwas tut. Ich habe das mit dem HDG-Selector vom MCP getestet und da dreht man schon eine Weile... Es gibt anscheinend Encoders mit verschiedenen "Rastungen" (4:1, 2:1 oder 1:1). Daher meine Frage: welche habt ihr da verbaut? Oder generell die Frage: woher habt ihr die ganzen Schalter, Encoders etc? Hispapanels/OC oder doch vom Elektromarkt um die Ecke?

 

Danke (wiedereinmal) vorab für eure Antworten.

LG

Michael

Hoi Michael

 

Meiner Erfahrung nach gibt es zwei Sorten von Encodern

1) solche mit 2 Pulsen pro Bewegung, also insgesamt 2x2 bits pro Bewegung wie z.B. mein Lieblings-Dual Encoder mit Pushbutton ELMA E37, hat richtig viel Haptik: http://leobodnar.com/shop/index.php?main_page=product_info&products_id=196

2) solche mit 1 Puls pro Bewegung, also 2 bits pro Bewegung. Es ändert nur immer einer der Anschlüsse. Wie z.B. mein Lieblings Single Encoder von OC: https://www.opencockpits.com/catalog/encoder-with-pushbutton-p-100.html?cPath=24_55

 

Der zweite ist recht einfach zu programmieren, sowohl mit dem OC, SISMO wie auch mit Arduino. Timing ist eher Nebensache. Wenn man bei OC oder SISMO zu schnell dreht, geht immer mal wieder ein Schritt verloren. Mit Arduino habe ich da mehr Freiheit. Eine Abtastfrequenz von 10 ms ist nicht schlecht aus meiner Erfahrung.

 

Der erste mit 2 Pulsen ist eher schwierig, weil die beiden Pulse pro Bewegung schnell aufeinander folgen. Geht mit OC perfekt, da die Karte nur sendet, wenn sich was ändert. Bei SISMO ist es so an der Grenze. Mit Arduino bin ich genau bei dem am Pröbeln. 10 ms genügt nicht. Kann ich bei Arduino anstelle mit digitalRead() auch mit Interrupts arbeiten?

 

Ist es möglich, dass deine Software auf 2 Pulse pro Bewegung wartet und du bei der Software noch den richtigen Encoder-Typ mit einem Puls pro Bewegung spezifizieren musst? Schau doch mal wie sich die beiden Inputs ändern bei jeder Encoder-Bewegung:

 

Bei 2) wäre es 01 dann 11 dann 10 dann 00 und dann wieder 01 etc. für 4 detents

Bei 1) wäre es 01 11 dann 10 00 dann 01 11 dann 10 00 und dann wieder 01 11 etc. für 4 detents

 

Ich hoffe, du kommst auf einen grünen Zweig damit

Reto

[Reto Stöckli]

On 3/14/2021 at 7:11 PM, Alpin-Flier said:

 

Ich halte mich an den Grundsatz: Traue keiner Studie, die Du nicht selbst gefäscht hast . Im Ernst, wenn ich mich nur aufs Internet verlassen hätte, wären bei mir jetzt auch mehrere PCs verbaut. Die Motorregelung über SIOC ist kein Neuland für mich. Beim Throttle und der Trimmung funktioniert das schon sehr gut. Ich kann wahrscheinlich dieselben Routinen auch für den Force-Feedback verwenden. Das sind nur wenige Scriptzeilen pro Motor. Mein Trick: nicht die Aenderungen (event-gesteuert wie sonst üblich) als Trigger für den Regelkreis verwenden, sondern einen Timer-gesteuerten Zyklus

- Regelkreis wird linear und ist trotzdem noch schnell genug

- geringe Programmbelastung

Ob das schliesslich auch für Force-Feedback klappt, wird sich weisen. Zumindest bin ich mit der Hardware durch. Hier ein paar Bilder dazu:

 

 

Es war übrigens nicht gerade einfach, Motoren und Gestänge nachträglich einzubauen. Dank der Motion konnte ich die Plattform aber einfach auf 30 cm anheben und darunter kriechen. Ein zugegebenermassen etwas mulmiges Gefühl... aber ich lebe noch . Nun geht's an die SW.

 

LG Urs

Lieber Urs

 

Ich sehe, du machst ernst. Also kein Prototyp mit Holz-Yoke, sondern grad richtig unter deiner Motion-Plattform verbaut. Und du hast schon recht, gewisse Dinge muss man einfach selbst in die Hand nehmen und es probieren. War wohl auch der Grund, warum ich dann die Hardware und Flusi-Plugin selbst geschrieben habe.

 

Ich drücke dir von Herzen die Daumen und bin gespannt zu hören, ob deine Linearisierung des Force-Feedbacks funktioniert! Sag mal, welche Motoren-Steuerung/Endstufe/H-Brücke verwendest du, dh. ich spreche die blaue Platine auf dem Kühler an? Ich würde dann mal so eine vom Arduino ansteuern versuchen ...

 

Alles Gute

Reto

[Reto Stöckli]

On 3/14/2021 at 4:36 PM, EdeBanatzke said:

Hallo Reto,
erstmal danke für dein Feedback.

...

So, nun zum Protokoll:

Der MSFS 2020 sieht ja optisch schon verführerisch aus und läuft auf meinem Setup richtig gut, Aber.

Die Airliner sind bis jetzt reines Spielzeug, das wird sich m. Meinung nach auch in den nächsten 2 Jahren nicht ändern.
Für meinen Anspruch an Systemtiefe an das Flugzeug (HC-Anbindung).

Seis Drum, ich möchte mein Setup so vorbereiten, das ich wenn ich will ohne großen Aufwand den Sim wechseln kann und wieder zurück.

Hier schwebt mir ein Protokoll vor, mit dem ich an den Arduinos, Raspis, usw. keine Hand anlegen muss. Die kommunizieren mit einem Serverprozess, der wiederum die Aufrufe empfängt und je nach laufendem Sim in die richtigen Variablen und Commands hi- und her übersetzt.

Ich werde mir dein Protokoll gerne ansehen und mal versuchen mit einem ESP über dein Protokoll Funktionen zu realisieren.
Ist dein Xplane-Plugin auch für Windows  vorhanden. hab noch nicht nachgesehen.

Ich würde mich  mit Dir, Reto gerne mal über meine Vorstellungen evtl. telf. austauschen. Hier dauert mir die schreiberei zu lange, sollte was sinnvolles aus diesem Gespräch werden so soll es natürlich auch hier diskutiert werden.

 

 
LG Piki

Lieber Piki

 

Dein Setup macht Endruck, und du packst möglichst viel I/O Hardware mit rein, die du selbst programmieren kannst. Mit Teensy hab ich selbst noch nicht gearbeitet, aber ich glaub das geht in die Richtung Arduino, richtig?

 

Deine Frage nach einem Protokoll, dass mit den verschiedenen H/W Komponenten kommunizieren kann, würde ich mit "ja" beantworten. xpcockpit wird dich hier allenfalls bedienen können. Das Plugin und auch der test client (xpclient) wie auch das Glass Cockpit (xpopengc) und auch die OC Schnittstelle (xpusb) sind auf Windows kompilierbar mit minGW. Arduino und Sismo hab ich bis jetzt erst auf Linux entwickelt. Ich habe für die Kompiliermüden auch mal ein Binary des Plugins und des Test Clients und OpenGC gemacht: https://github.com/retostockli/xpcockpit/blob/master/xpcockpit-windows.zip . Wohlgemerkt: das wär nur ein Demo, du wirst um code editieren und kompilieren nicht herumkommen. Es ist aber alles in C geschrieben.

 

Jetzt zu der grossen Herausforderung. Deine Frage nach einem Plugin und Protokoll das mit aller Hardware und mit mehreren Flugsimulatoren kommunizieren kann, kann ich vorerst mit "nein" beantworten. Mit dem simplen Grund: das xpcockpit Protokoll arbeitet explizit mit den X-Plane Datarefs. Gibt es bei MSFS eine analoge Form? Kann ich bei MSFS z.B. über ein API eine Variable/Button/Annunciator wie z.B. "MCP HDG" per String suchen und dann mittels Pointer etc. auf sie zugreifen? Falls man es schaffen könnte, dies auch bei MSFS zu machen, dann wäre es im Fall recht nett, mein Protokoll so zu erweitern, dass man auch bei MSFS Variablen "abonnieren", "beziehen" und auch wieder "abbestellen" kann von Seiten des angeschlossenen Clients, so wie ich dies bei X-Plane tue.

 

Lass mal hören

Reto

[Alpin-Flier]

vor 10 Stunden schrieb Reto Stöckli:

Sag mal, welche Motoren-Steuerung/Endstufe/H-Brücke verwendest du, dh. ich spreche die blaue Platine auf dem Kühler an?

Hoi Reto

 

Es handelt sich um den Adafruit 3190 aus dem Dunstkreis von Arduino und Rasperry. Ein geniales Modul, moderne FETs, Strom- und Temperaturüberwachung, und zu einem unschlagbaren Preis. Bekommst Du z.B. bei Distrelec und Mouser.

 

https://www.distrelec.ch/de/dc-motortreiber-drv8871-adafruit-3190/p/30129208

 

Interessant ist auch die Ansteuerung bezüglich Ruhelage. Sind beide Inputs auf 0, ist die Brücke offen, d.h. der Motor ist frei beweglich. Sind beide auf 1, ist der Motor kurzgeschlossen und bremst Bewegungen ab. Da die Opencockpitskarte positive PWM-Pulse erzeugt, passt das wunderbar.

 

LG Urs

Bearbeitet 17. März 2021 von Alpin-Flier