DLP084

Members
  • Content Count

    389
  • Joined

  • Last visited

Community Reputation

5 Neutral

About DLP084

  • Rank
    Member

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No
  1. DLP084

    Newest installer corrupts RAAS for FS9

    The same (FS2Crew menu bar removed) is also happening on Windows 7. So both, Windows XP and Windows 7 are affected by a corrupted FS9 installer that makes Raas unuseable. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- update: Strange..... for some reason the FS2Crew menu bar appeared again after FS9 was started a second time on windows 7. I only wonder if it will do the same on windows XP. Best Regards, Jan-Paul
  2. Hi, the newest installer (downloaded today) removes the FS2Crew menu bar for the FS9 installation on Windows XP. In addition PMDG 737 FS9 creates PMDG main.gau errors Reverting back to RAAS version 1.3.2.60 makes everything working fine again. Best Regards, Jan-Paul
  3. DLP084

    my 777 lands near runway

    Hi, ILS 04R has an offset Localizer. Therefore it is intentional that it doesn´t guide you exactly onto the RWY. ILS04L doesn´t have an offset. This one should work as expected. If not then it´s the registry problem. Jan-Paul
  4. DLP084

    LNAV turn prediction and LNAV path drawn in general

    Hi, the way you are using the AFDS systems to fly the approaches, can only lead to those drawings you see on the ND. The published approaches are not designed by Austrocontrol to be flown that way. Its not a problem with the aircraft. Its a problem on how the aircrafts autoflightsystems are supposed to be used to fullfill a specific task. In your case flying with HDG select and then establishing a reasonable intercept onto the intended path of the procedure designer would be the better option. Flying from RTT directly to ELMEM is way beyond the limits of the published approach procedure. Every approach procedure "looks funny" when it is not used in accordance with the procedure designers intentions. Jan-Paul
  5. DLP084

    RJOO SID ASUKA4 errors at PMDG 777

    Hi, there is no other solution as to live with those intercepts with turns over 180 degrees. At the moment the limited PMDG syntax doesn´t allow CF (course to fix) or CI (course to intercept) legs with turn directions. The only realistic way to get them flown in proper way is as follows: 1. Use HDG select and turn manually with the mandated turn direction onto the INTC heading (left 071). 2. When established on INTC heading (071) select DCT to FIX (ASUKA) and use INTC CRS function to enter the course (101) to the fix (ASUKA) 2.1. If the intercept is going into between two waypoints. A PBD fix along this line could be created to avoid long course to fix legs. comment to Mystery 2: that is against the intention of the ARINC 424 source, as the A/C arrives at ASUKA and does a left turn back to ASKUKA again. Translated to ARINC 424 Path Terminators this would read as follows: CA 332° +500ft - VI (L) 071 - CF 101° (ASUKA) - DF (L) ASUKA + 5000 But PMDG is actually doing the following when flying that coding: It skips HDG 071 INTERCEPT RADIAL 101 TO FIX ASUKA and does TURN LEFT FIX ASUKA So thats nothing else than: RNW 32L TRK 322 UNTIL 500 TURN LEFT DIRECT FIX ASUKA AT OR ABOVE 5000 which in fact ignores the 101 Radial The only way to solve such issues permanently without pilot intervention is, if PMDG develops a new format that handles all the details that are incorporated in the ARINC 424 Path Terminator language. For more reading about path terminators have a look here: http://www.keilir.net/static/files/Flugakademian/PDF/rnavmanual-kka.pdf
  6. Thats not implemented in the PMDG 747. Does the real world have this feature meanwhile? The only way to intercept an airway would be via DCT to fix and entering an INCT CRS while already established on INCT HDG. If the distance is too big for a course leg, a along track fix on the line of the FROM AWY fix to the TO AWY fix could be created in between to avoid a course leg longer than 20 miles for example. FFF/#DD FFF=Fix #=+- DD=Distance Jan-Paul
  7. That seems to be a old AFCAD File that creates the trouble. Disable ALL add on sceneries and remove all non default AFCAD files out of the Add On Scenery folder. Jan-Paul
  8. DLP084

    PilotsEYE.tv | QUITO | MD-11F

    Depends on your player if it supports PAL. From the FAQ: http://pilotseye.tv/en/faq/ Jan-Paul
  9. DLP084

    Navigraph or NavDataPro

    Thats very well spotted. This example shows one of the major differences between Lufthansa Systems and Jeppesen: Lufthansa Systems always uses the DME Identifier for Final Approach fixes, whereas Jeppesen sticks to the ARINC 424 Naming Convention. e.g. FI27R = Final Approach Fix ILS RWY 27R That naming convention was one of the contributing factors to the cali accident: http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/Cali/calirep.html Those who want to know more about the ARINC 424 Conventions: http://www.keilir.net/static/files/Flugakademian/PDF/rnavmanual-kka.pdf Jan-Paul
  10. DLP084

    BRBBQ ONE STAR into KMEM

    This is a known problem. The PMDG MD-11 doesn't seem to be able to handle "at or below" constraints and treats them as "at" constraints. Workaround: Delete the "at or below" and see what the FMC calculates. If its above, the use the "at or below" constraint. If its below then keep the calculated value. Jan-Paul
  11. DLP084

    ILS alignment issues

    The course displayed on the PFD (number 2 circled) is always the correct one, as this is the result of the FS TRUE Bearing + the variation stored in the magdec.bgl All other courses have to be ignored. So always look what the PDF displays and set the NAV/RAD course according to that value. Otherwise you are going to fly an offset. The 206 is the correct "FS" course in your case. Updating the magvar.bgl helps to get that value closer to the real one. Jan-Paul
  12. DLP084

    ILS alignment issues

    Guys, there is no need to apply the Magnetic Variation Corrector to BGL Files. It has no influence on the navigation of the aircrafts. It only changes the displayed courses on the map view (world/map) within the navaid list. The indicated values on the aircraft instruments and SHIFT + Z have already been changed by the magdec.bgl Jan-Paul
  13. DLP084

    ILS alignment issues

    Could you please try the following: Disable ALL Add On sceneries (including Add On Scenery folder itself) and try again with default scenery only. If that solves your problem, enable each add on scenery step by step to find the afcad file that causes the trouble. With FS9, corrupted afcads anywhere in the world were known to create such problems. Could be the same with FSX. But I am not sure about this as I dont use FSX. But maybe its worth a try. Jan-Paul
  14. In Both cases yes. The new magnetic declination will make the FS Bearings matching more or less the current published ones. + / - 2° of tolerance can be expected due to the fact that state sources (AIPs) are not always adhering to the current magnetic variation. Jan-Paul
  15. But that one is only useful to correct the variation inside the afcad files. It has no influence on the behavior of the aircrafts. The AFCAD variation is used, to determine the bearings for the internal fs map as well as for some external applications like FSNavigator or the MakeRWYs tool from Pete Dowson. If the tool does not correct the variation, you still have the old bearings on the map display (facility information), whereas the aicrafts show the new values according to the magdec.bgl Jan-Paul