Everything posted by DLP084
- my 777 lands near runway
-
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
-
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
-
Approach Headings wrong in FMC
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
-
PilotsEYE.tv | QUITO | MD-11F
Depends on your player if it supports PAL. From the FAQ: http://pilotseye.tv/en/faq/ Jan-Paul
-
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
-
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
-
MD-11 ctd at 4,000' ASL
Hello Brandon, take a look at the following posts: http://forum.avsim.net/topic/412826-md-11-crashes-on-selecting-sid-or-star/ It is important that your route has no discontinuities and the distance between T/C and T/D is sufficient to allow a normal CRZ phase. Form your report, it seems that the FMS reaches T/D before T/C. Thats one of the causes for CTDs, because the FMS doesn't sequence properly through CLB, CRZ and DES phases. Jan-Paul
-
Video Discussion: PilotsEYE.tv - QUITO - MD-11F - Lufthansa Cargo - "The Lady and the closed Strip"
Name: PilotsEYE.tv - QUITO - MD-11F - Lufthansa Cargo - "The Lady and the closed Strip" Category: Commercial Product Videos Date Added: 23 November 2013 - 10:43 PM Submitter: DLP084 Short Description: None Provided Post Source: PilotsEYE.tv - QUITO - MD-11F - Lufthansa Cargo - "The Lady and the closed Strip" View Video
-
PilotsEYE.tv - QUITO - MD-11F - Lufthansa Cargo - "The Lady and the closed Strip"
Hi, the trailer looks very promising: http://www.youtube.com/watch?v=DLuTLCxYJvM Jan-Paul
-
LNAV drifts, won't hold course
Its not a weather issue! Its an AFCAD issue. I had the same problem a long time ago at the time the 747 was released 2005. The trouble maker was an bad AFCAD file for fs2002. Solution: Disable all Add On scenerys and check if the aircraft is flying correct. Then, enable the add on scenerys step by step to find the bad AFCAD. The reason why you don´t have the problem with the LEVEL-D 767 is because it has its own magvar model. PMDG uses the default or updated magdec.bgl file. The bad AFCAD Files are interfering with it and create this problems. The best area to test, is far up in the north. I was flying at Ketchikan PAKT when I discovered the problem 2005. If it behaves OK here, then everywhere. Jan-Paul
-
REMOVE THE HOLDING AUTO WITHIN THE STAR
Hi, the holdings are from the Navigraph database: See release notes: http://www.navigraph.com/forum/viewtopic.php?f=22&t=564 added IAF holdings in EFB (including PMDG, iFly, LevelD, ...) NavdataPro does NOT include them, as it should be in real world. Example from LFMN: Navigraph: TRANSITION NERAS HOLD AT FIX NERAS RIGHT TURN INBOUNDCOURSE 298 ALT 4000 LEGDIST 5 NavdataPro: TRANSITION NERAS FIX NERAS AT 4000 Jan-Paul
- "Invalid Entry" Terminal Waypoints in FMC
-
"Invalid Entry" Terminal Waypoints in FMC
Another Theory: Maybe the 777 expects the "Terminal Waypoints" to be inside the SID/STAR file? At the moment, they are only defined in the wpNavFIX.txt Does adding a waypoint to LEGS page or selecting a DCT to a waypoint that is defined in the SID/STAR file work, without being preloaded on the LEGS page? Examples from the EDDF SID/STAR File: FIX DF132 LATLON N 50 6.98883 E 8 19.35250 FIX DF133 LATLON N 50 1.83600 E 8 26.80850 FIX DF134 LATLON N 50 1.72900 E 8 31.12633 FIX DF135 LATLON N 50 1.46617 E 8 31.27367 FIX DF136 LATLON N 50 0.66650 E 8 17.01767 FIX DF137 LATLON N 49 57.95533 E 8 31.70733 FIX DF138 LATLON N 49 58.33717 E 8 25.35467 FIX DF139 LATLON N 50 3.41200 E 8 38.22000 FIX DF140 LATLON N 50 3.12150 E 8 38.24600 FIX DF141 LATLON N 50 1.07467 E 8 30.12383 FIX DF142 LATLON N 50 0.51217 E 8 29.81300 FIX DF143 LATLON N 49 58.96433 E 8 28.94983 FIX DF144 LATLON N 50 2.86950 E 8 35.93917 FIX DF145 LATLON N 50 2.60617 E 8 36.07700 FIX DF146 LATLON N 50 6.02033 E 8 38.04317 FIX DF149 LATLON N 50 4.36450 E 8 42.64283 FIX DF150 LATLON N 50 0.61483 E 8 45.10433 FIX DF151 LATLON N 50 3.45517 E 8 50.61600 FIX DF152 LATLON N 50 4.23317 E 8 42.48050 FIX DF153 LATLON N 49 50.48150 E 8 41.43117 FIX DF154 LATLON N 49 58.70233 E 8 35.65467 FIX DF155 LATLON N 49 54.77317 E 8 42.98100 FIX DF156 LATLON N 49 56.03667 E 8 27.46517 FIX DF157 LATLON N 49 47.46600 E 8 40.33767 FIX DF158 LATLON N 49 58.00017 E 8 31.58300 FIX DF159 LATLON N 49 56.97650 E 8 34.41867 FIX DF160 LATLON N 49 52.41917 E 8 32.09700 FIX DF162 LATLON N 50 0.58733 E 8 29.77500 FIX DF163 LATLON N 49 55.92350 E 8 27.27983 FIX DF164 LATLON N 49 51.73450 E 8 21.03717 FIX DF165 LATLON N 50 0.14300 E 8 29.71167 FIX DF166 LATLON N 49 57.29400 E 8 29.33000 FIX DF168 LATLON N 49 56.34950 E 8 36.16767 FIX DF169 LATLON N 50 3.87050 E 9 17.00367 FIX DF170 LATLON N 50 0.92000 E 8 29.77167 FIX DF171 LATLON N 50 0.45750 E 8 29.55183 FIX DF172 LATLON N 49 54.87617 E 8 26.96600 FIX DF180 LATLON N 49 54.31217 E 8 26.70400 FIX DF197 LATLON N 49 58.77867 E 8 31.57683 FIX DF198 LATLON N 49 45.06133 E 8 27.95217 FIX DF200 LATLON N 49 43.20083 E 8 26.90767 FIX DF201 LATLON N 49 47.25300 E 8 14.37167 FIX DF233 LATLON N 50 1.99900 E 8 25.27833 FIX DF234 LATLON N 50 1.59083 E 8 30.58950 FIX DF235 LATLON N 50 1.36283 E 8 30.86233 FIX DF236 LATLON N 50 1.43133 E 8 23.40650 FIX DF237 LATLON N 50 2.34600 E 8 20.43567 FIX DF238 LATLON N 50 7.70883 E 8 15.93083 FIX DF270 LATLON N 50 1.62450 E 8 8.56900 FIX DF271 LATLON N 49 52.18717 E 8 13.64783 FIX DF272 LATLON N 49 56.90950 E 8 11.10850 FIX DF273 LATLON N 50 5.57633 E 8 48.40767 FIX DF275 LATLON N 50 1.36417 E 8 8.70950 FIX DF276 LATLON N 49 51.92683 E 8 13.78700 FIX DF277 LATLON N 49 56.64550 E 8 11.25050 FIX DF278 LATLON N 50 3.35267 E 8 50.63683 FIX DF281 LATLON N 50 7.58467 E 8 55.78033 FIX DF282 LATLON N 49 59.01517 E 8 20.77333 FIX DF289 LATLON N 50 7.32100 E 8 55.92233 FIX DF290 LATLON N 50 1.22817 E 8 30.27817 FIX DF291 LATLON N 49 59.71083 E 8 27.07550 FIX DF401 LATLON N 49 59.59183 E 7 56.96500 FIX DF402 LATLON N 50 4.38200 E 8 16.29133 FIX DF403 LATLON N 50 5.80217 E 8 22.50100 FIX DF406 LATLON N 50 21.73650 E 9 15.49367 FIX DF407 LATLON N 50 23.69250 E 9 10.53517 FIX DF408 LATLON N 50 15.97900 E 8 37.62933 FIX DF409 LATLON N 50 10.22133 E 8 40.99900 FIX DF416 LATLON N 50 19.75867 E 9 21.87150 FIX DF422 LATLON N 50 9.61667 E 9 1.03950 FIX DF426 LATLON N 50 15.05067 E 9 24.50283 FIX DF431 LATLON N 50 4.65850 E 7 51.43817 FIX DF432 LATLON N 50 12.40750 E 8 23.32383 FIX DF436 LATLON N 50 13.86917 E 9 16.92183 FIX DF437 LATLON N 50 16.27517 E 9 6.78017 FIX DF439 LATLON N 50 6.76950 E 8 26.54650 FIX DF444 LATLON N 49 57.59467 E 7 48.93650 FIX DF452 LATLON N 49 55.76917 E 8 3.28433 FIX DF454 LATLON N 49 52.92367 E 7 51.70100 FIX DF601 LATLON N 49 56.36817 E 8 32.31100 FIX DF607 LATLON N 50 1.10150 E 9 14.92967 FIX DF608 LATLON N 49 55.84133 E 8 52.49283 FIX DF609 LATLON N 50 0.54017 E 8 49.82450 FIX DF613 LATLON N 50 5.30167 E 9 10.09517 FIX DF616 LATLON N 50 9.36133 E 9 27.67017 FIX DF621 LATLON N 50 7.26783 E 8 55.74333 FIX DF623 LATLON N 50 10.00400 E 9 7.44883 FIX DF626 LATLON N 50 14.07050 E 9 25.04950 FIX DF631 LATLON N 50 0.37267 E 8 12.73550 FIX DF632 LATLON N 50 1.25533 E 8 20.52883 FIX DF635 LATLON N 49 58.94567 E 8 43.01633 FIX DF636 LATLON N 49 55.60533 E 8 29.13433 FIX DF644 LATLON N 49 47.29333 E 7 55.02100 FIX DF651 LATLON N 49 56.22483 E 8 9.64633 FIX DF654 LATLON N 49 51.96550 E 7 52.26750 FIX DF901 LATLON N 50 3.63133 E 8 52.16650 FIX DF902 LATLON N 50 5.09400 E 8 59.00150 FIX DF907 LATLON N 50 0.86717 E 8 57.94450 FIX DF910 LATLON N 49 57.23117 E 8 21.21467 FIX DF911 LATLON N 49 55.83683 E 8 14.87583 FIX DF914 LATLON N 49 52.69783 E 8 22.09183 FIX DF920 LATLON N 49 57.13783 E 8 20.78883 FIX DF950 LATLON N 49 50.16900 E 8 40.39133 FIX DF951 LATLON N 50 4.26100 E 8 0.49033 Jan-Paul
-
"Invalid Entry" Terminal Waypoints in FMC
Hi, no its not a Navdata issue. It should basically work like on the NGX. If not it seems to be a bug. In my real life job I am doing the Navdatabase coding for one of the big Dataproviders. These RNAV waypoints are not included in the procedure coding because they have no specific function (speed / altitude / track). They are supposed to be selected as DCTs if needed. There is also a coding table according to which the datas are coded: Germany for example only includes the edge waypoints in the table. Other countries like turkey, include every waypoint and not only the edge waypoints: There should be no difference when using NavdataPro or Navigraph, as LIDO and Jeppesen have the same coding here. As I don´t own the 777 I cant verify the FMS behavoir by myself. Question: Does adding the waypoints to the LEGs page first and then selecting them as direct work? Jan-Paul
-
MD-11 Crashes on selecting SID or STAR
The reason for the crashes at same dept/dest, is that T/D can appear before reaching T/C. That case leads to a 100% crash as soon the A/C passes T/D and it is stiil in CLB Phase. At same dept/dest it is very important to have enough waypoints available to allow proper transfer into CRZ phase. Its irrelevant if those additional waypoints are acutally used or skipped later. They only are there to support the FMS Phase switching. Generally the crash happens as soon one phase is left out e.g. CLB dct DES vv without CRZ. This is the reason why the crashes happen that often with same dept/dest. Jan-Paul
-
MD-11 Crashes on selecting SID or STAR
Robin, the CTD has to do with waypoints selection and the current phase the fms is in, but not in the way you described. Here is the solution: http://forum.avsim.net/topic/400619-ctd-using-the-pmdg-md-11/ Jan-Paul
-
RNP Appch
Basically the NGX can fly it. But it is not the same as it would be if AF and RF-Legs would be supported directly without creating additional fixes that are necessary to interpolate the ARCs. With NavdataPro additional waypoints are created between the start and the ending fix of an arc to interpolate it. The distance of this fixes is approximately 3nm between each other. The arc is then not flown perfectly with a constant bank angle like in reality because of the straight segments. But it is working quite nicely when considering the limitation of the current PMDG data format. Just try out KPSP for example. Jan-Paul
-
RNP Appch
Technically there is not much difference in ARINC 424. Both are ARCs on a specific radius around a center fix. On AF-Legs its the VOR and on RF-Legs its a database fix. So if the current PMDG Format would support AF-Legs it would be absolutely no problem to implement RF-Legs. Jan-Paul
-
RNP Appch
Thats only partially true. When using NavdataPro, RF-Legs are interpolated just like AF-Legs. It is still not the real thing but better than nothing. PMDG mentioned in an earlier posting, that this is going to change in the future as a new data format is in development. Jan-Paul
-
FMC strange SID at EKBI
Which Navdata Provider are you using? Navigraph or Aerosoft? The FMS Coding contains several whichever is later conditions, that could look odd on the ground. As soon the aircraft is airborne, the SIDs from RWY 27 should be flown without any problem. Jan-Paul
-
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
-
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
-
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
-
Add ILS approach waypoints?
This is also a result of different naming conventions between the navdata providers. Navigraph uses Jeppesen and Aerosoft uses Lido. Here is the way it looks in NavdataPro: APPROACH ILS25L FIX IBL58 AT 2000 FIX OBNB AT 1410 SPEED 160 RNW 25L TRK 250 UNTIL 700 HDG 119 INTERCEPT RADIAL 085 TO FIX FLO FIX FLO AT 4500 TRANSITION ANT FIX ANT SPEED 220 FIX OVERFLY BUN FIX IBL11 AT OR ABOVE 2000 TRANSITION FLO FIX FLO SPEED 220 FIX FLO81 FIX IBL14 AT OR ABOVE 3000 FIX IBL89 AT OR ABOVE 3000 TRANSITION KERKY FIX KERKY SPEED 220 FIX OVERFLY BUN FIX IBL11 AT OR ABOVE 2000 The difference here is, that the waypoints use the DME ident + distance as identifier. Jeppesen on the other hand is using a naming convention based on their function. CI25l means "Final Approach Course Fix ILS 25L". For pilots the DME Distance convention may be the better one, as it enhances the situational awarenes regarding the geographical position of that waypoint. For database editors the naming convention based on function may be better, because you can connect them to their database role and easily use it on multiple approaches without having to figure out the dme distance name every time you want to use the same waypoint on a different approach. Here as example ILS25L with FLO transition. Jeppesen: D070P = D13.9 IBL D070K = D8.9 IBL CI25L = D5.8 IBL OM25L = D3 IBL Lido: IBL14 IBL89 IBL58 OBNB (OB NDB) In the end, there is no need to add any waypoints, as all of them are there already. You may just forgot to select the FLO transiton. Jan-Paul