Beiträge von Binford

London City hat schon seit Jahren einen "ferngesteuerten" Tower.

Being a NATS Air Traffic Controller in London City Airport's Digital Tower

Was genau? Du hast den Justsim EDDV quasi während des Fluges installiert und wolltest dann, dass dieser genutzt wird? Ich glaube, dass kann der MSFS nicht. Da musst du den Sim beenden, den Airport dann installieren, den Sim starten und dann in deiner Bibliothek im Sim ggf. den Standard Airport deaktivieren (falls es einen Asobo Handcrafted gibt).

Möglich. Bin gespannt, ob sich das ganze wirklich aufklären lässt.

Aber auch dann legen sich die Schalter nicht von alleine um.

Okay.

Naja, bevor ich mir jetzt weiter den Kopf darüber zerbreche und im Endeffekt doch keine Ahnung habe, was der Hintergrund für das dort geschehene ist, warte ich lieber weiter die offiziellen Ermittlungsergebnisse ab.

Die EICAS Message dürft ein dem Fall wohl "ENG SHUTDOWN" sein.

Kommt einem als Pilot in diesem Fall sofort in den Sinn, dass der Kollege die Switche umgelegt hat?!

Möglich, aber würde ich doch stark bezweifeln. Irgendwie passt das alles eben nicht zu der Frage des Piloten, die doch recht eindeutig ist.

Der FDR zeichnet das elektrische Signal auf, welches von den Switchen kommt. Nicht die wirkliche Position der Switche. Trotzdem ist es aus meiner Sicht nahezu unmöglich, dass beide Switche, die völlig unabhängig voneinander sind, mit dem Abstand von 1 Sekunde technisch versagen. Das die Switche von alleine, ohne Fremdeinwirkung, ihre Position wechseln ist dagegen nun wirklich auszuschließen. Wie soll das gehen?! Auch das gleichzeitige versagen der mechanischen Schutzvorrichtung, die verhindert, dass man versehentlich die Switche betätigt, ist aus meiner Sicht nicht vorstellbar. Bei einem Switch vielleicht, bei beiden? Never ever. Die Hände sind normalerweise in dieser Flugphase auch weit weg von den Switchen, so das man da auch nicht versehentlich rankommen kann.

Dazu passt auch nicht die Frage des einen Piloten, wieso sein Kollege die Switche in Cutoff gesetzt hat. Diese Aussage bedeutet für mich, dass der eine den anderen entweder dabei gesehen hat, wie er die Switche umgelegt hat, oder aber er hat die Switche in Cutoff gesehen. Wie sollte man sonst so schnell zu dieser eindeutigen Nachfrage kommen?

Passt alles nicht. Für mich hat hier einer der beiden die Switche in Cutoff gesetzt. Was der Grund dafür war, bleibt weiter zu ermitteln.

Technisches versagen ist zwar nicht gänzlich auszuschließen, aber mMn mehr als unwahrscheinlich.

Das einer der beiden Piloten die Switche in Cutoff gesetzt hat.

EDIT : Oder ggf. jemand anderes der mit im Cockpit war.

Zitat

India's AAIB has released its Preliminary Report into the crash of AI flight 171:

The aircraft achieved the maximum recorded airspeed of 180 Knots IAS at about 08:08:42 UTC and immediately thereafter, the Engine 1 and Engine 2 fuel cutoff switches transitioned from RUN to CUTOFF position one after another with a time gap of 01 sec. The Engine N1 and N2 began to decrease from their take-off values as the fuel supply to the engines was cut off. In the cockpit voice recording, one of the pilots is heard asking the other why did he cutoff. The other pilot responded that he did not do so.

As per the EAFR data both engines N2 values passed below minimum idle speed, and the RAT hydraulic pump began supplying hydraulic power at about 08:08:47 UTC.

As per the EAFR, the Engine 1 fuel cutoff switch transitioned from CUTOFF to RUN at about 08:08:52 UTC. The APU Inlet Door began opening at about 08:08:54 UTC, consistent with the APU Auto Start logic. Thereafter at 08:08:56 UTC the Engine 2 fuel cutoff switch also transitions from CUTOFF to RUN. When fuel control switches are moved from CUTOFF to RUN while the aircraft is inflight, each engines full authority dual engine control (FADEC) automatically manages a relight and thrust recovery sequence of ignition and fuel introduction. The EGT was observed to be rising for both engines indicating relight. Engine 1’s core deceleration stopped, reversed and started to progress to recovery. Engine 2 was able to relight but could not arrest core speed deceleration and re-introduced fuel repeatedly to increase core speed acceleration and recovery. The EAFR recording stopped at 08:09:11 UTC At about 08:09:05 UTC, one of the pilots transmitted “MAYDAY MAYDAY MAYDAY”. The ATCO enquired about the call sign. ATCO did not get any response but observed the aircraft crashing outside the airport boundary and activated the emergency response. At 08:14:44 UTC, Crash Fire Tender left the airport premises for Rescue and firefighting. They were joined by Fire and Rescue services of Local Administration.

The flap handle assembly sustained significant thermal damage. The handle was found to be firmly seated in the 5-degree flap position, consistent with a normal takeoff flap setting. The position was also confirmed from the EAFR data. The landing gear lever was in “DOWN” position.

The thrust lever quadrant sustained significant thermal damage. Both thrust levers were found near the aft (idle) position. However, the EAFR data revealed that the thrust levers remained forward (takeoff thrust) until the impact. Both fuel control switch were found in the “RUN” position. (fig.13) The reverser levers were bent but were in the “stowed” position. The wiring from the TO/GA switches and autothrottle disconnect switches were visible, but heavily damaged.

The aircraft is equipped with two Enhanced Airborne Flight Recorders (EAFR) part number 866-0084-102. The EAFR are fitted at two locations, one in the tail section at STA 1847 and other in the forward section at STA 335. The two EAFRs are similar in construction and record a combined data stream of digital flight data and cockpit voice information, with both stored on the same device.

The downloaded flight data contained approximately 49 hours of flight data and 6 flights, including the event flight. The recovered audio was two hours in length and captured the event. Initial Analysis of the recorded audio and flight data has been done.

Alles anzeigen

Zitat von Harry320

Als ich von WIN10 auf WIN11 gewechselt habe, war es Windows 11 Version 22H2.

Da ist mir nichts aufgefallen. Ich meine, dass es erst seit dem Update auf Windows 11 Version 24H2 aufgetreten ist.

Jedenfalls nervt es total.

Ließt man oft, dass es da einen Zusammenhang geben kann/muss.

Zitat von Harry320

Binford das exakt gleiche Problem mit dem stotternden Sound und der 100% Auslastung der CPU habe ich auch, jedoch im MSFS 2020,

allerdings erst, seit ich von WIN10 auf WIN 11 gewechselt habe. Vorher gab es nie Probleme. Manchmal hilft ein Neussart des PC's, manchmal der Neustart des MSFS

Gelegentlich hilft garnichts ausser warten...

Alledings habe ich auch NVIDIA High Definition Audio im Verdacht. Das habe ich jetzt mal im Geräte-Manager deaktiviert.

Seitdem hatte ich das Problem erst mal nicht mehr. Aber ich gehe davon aus, dass das nicht die Lösung ist...

Bei mir nur im 2024 und auch erst seit ich auf Windows 11 gewechselt bin.

Die letzten male wo es wirlich extrem war, habe ich den Sim neugestartet und jedes mal war es dann weg.

Ich hab keine Ahnung. Allerdings gibt es seitenlange Threads dazu auch im offiziellen Forum.

Manche haben es, manche nicht. Helfen tut so wirklich gar nichts. Zumindest nicht auf Dauer.

Zitat von oliver2308

Ja, das mache ich bisher au h so. Aber nachdem ich das vom FSLABS gelesen habe wäre es ja interessant, ob das beim Fenix auch geht.

Gibt es eine Seite auf der mcdu, wo man ein Gate eintragen kann?

Nein.

Zitat von Binford

Ich hab heute mal wieder extreme Sound Probleme. Stottern und kratzen die ganze Zeit. Unfliegbar!

Das ganze ist immer verbunden mit einer kurzzeitigen CPU Auslastung von 100% bei gleichzeitem CPU Temperatur Peak.

Allerdings scheint das ganze, wie auch immer möglich, mit den Servern zusammenzuhängen, da es an Wochenenden bzw. am Abend teilweise extrem ist, unter der Woche am Vormittag allerdings auch meistens gar nicht auftritt. Gestern hatte ich nichts, heute ist es nicht akzeptabel.

Der Sim macht immer noch keinen wirklichen Spaß.

EDIT : Rückflug, nachdem ich den FS einmal neu gestartet habe komplett problemlos. Als hätte er sich diesmal mit einem anderen Server verbunden.

Ich hab heute mal wieder extreme Sound Probleme. Stottern und kratzen die ganze Zeit. Unfliegbar!

Das ganze ist immer verbunden mit einer kurzzeitigen CPU Auslastung von 100% bei gleichzeitem CPU Temperatur Peak.

Allerdings scheint das ganze, wie auch immer möglich, mit den Servern zusammenzuhängen, da es an Wochenenden bzw. am Abend teilweise extrem ist, unter der Woche am Vormittag allerdings auch meistens gar nicht auftritt. Gestern hatte ich nichts, heute ist es nicht akzeptabel.

Der Sim macht immer noch keinen wirklichen Spaß.

Seid doch einfach alle froh, dass Ihr die Möglichkeit habt, zwischen zwei guten Produkten zu wählen. Dürfte für jeden das passende dabei sein und niemand muss sich für irgendwas rechtfertigen oder angegriffen fühlen.

Vielleicht dann jetzt auch wieder back to Topic

Zitat von Tobias

Inibuilds macht das vorallem und es nervt (und zeigt eigentlich nur, dass sie da faul sind, denn andere bekommen es hin beides zu bedienen). Denn im 24er kann ich New York JFK ohne PG nicht anfliegen, denn dann sind überall und vor allem auf der RWY, fetteste Kanten, welche einen weg-yeeten.

Mit PG an kann ich JFK aber auch nicht anfliegen, weil jedesmal wenn dann JFK+NYC laden, kneift der Sim vor Überlastung den Arsch zu.

Eine Übersicht welche Airports PG benötigen gibt es wahrscheinlich nicht oder?

Hatte jemand schon mal das Problem, dass sich GSX nicht mit Simbrief verbinden will?

Ich hab das Logging aktiviert und dies sagt mir : "Exception1 = SSL connect error"

Laut GSX Forum : Firewall oder Anti Virus blockiert die Verbindung. Aber selbst wenn ich alle Sicherheitsmaßnahmen von Windows abschalte, bleibt das Problem und die selbe Meldung bestehen. Hab es auch schon mit VPN probiert. No Help!

Das ganze trit bei mir erst seit meinem Update auf Windows 11 auf. Davor mit 10 hatte ich das nie.

Ich hab mal PG deaktiviert und seitdem keine bzw. kaum Ruckler/Stutter mehr und um einiges bessere FPS.

Wollte als nächsten Schritt mal mit dem Rolling Cache rumspielen und gucken, ob das mit PG dann besser wird. Wobei ich mir nicht sicher bin, ob ich PG überhaupt haben will.

Alles MSFS 2020.

Kein halber Tag vergangen und die ganzen selbsternannten Experten kommen mit steilen Thesen um die Ecke. Jeder, der nen bisschen Ahnung hat weiß, dass man sich nicht immer auf FR24 verlassen kann, trotzdem kommen jetzt viele mit "die hat ja gar kein Backtrack gemacht" ... Oder all die, die jetzt schon meinen Aufgrund irgendwelcher Handy/Überwachungsvideos in schlechter Qualität beurteilen zu können, dass die Flaps nicht gesetzt waren. Bla Bla Bla.

Hauptsache man hat irgendwas gesagt. Nervt!

Ich hab jetzt die AS Version im 2024er und die MK im 2020er gestestet. Bei beiden habe ich im Anflug massive Ruckler obwohl die FPS eigentlich Ok sind.

Verstehe ich nicht. Gibt es hier ein allgemeines "Düsseldorf" Problem oder sind Versionen da problematisch?