Skip to content
View in the app

A better way to browse. Learn more.

The AVSIM Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

PAPI view verification request!

Featured Replies

Up until 2 weeks ago, my PAPI and my GS indication coincided when crossing the end of the runway of a default airport.  Usually the Threshold Crossing Height was between 50-60 agl and if I slewed an aircraft to the height that centered the GS, the PAPI would also show on Visual Approach Path.  ( I am aware that VGSI on many airports DO NOT coincide but on the FSX default for the most part they did).

 

Now, however, if I bring the aircraft to the height that centers the GS needle the PAPI lights show too high.  And the forward cockpit view appears as though the PAPI are too close when the aircraft is placed at the runway end.

 

Would someone reading this please check the situation on your system using a default runway with ILS.  If you are not finding the same inconsistency then something must have changed in my system files  (VISTA 64) since a complete uninstall and reinstall of FSX still did not eliminate the discrepancy.   Google Chrome recently did a major upgrade and to my knowledge that is the only thing that could have affected my system since I have neither added nor changed anything.

 

If anyone can shed any light on my issue it would be greatly appreciated.  I am stumped!

 

Thanks.

In my experience the glide slope puts you farther down the runway (therefore, is above the visual glide slope indicator glide slope) in FSX, consistent with most RW approaches.  Not sure why you did not experience this before.  I hand-fly my approaches and so I have had plenty of opportunity to see where I am with respect to the visual glide slope indicator system (PAPI, VASI, the occasional PVASI) - a good sampling of being on, above and below the electronic glide slope :rolleyes: . 

 

If you're flying by the rules (for commercial carriers, at least) then you are required to be at or above the glide slope in use.  So - for the electronic glide slope you need to be at or above the center of the glide slope; for the visual, two red / two white (or the equivalent) or higher.  However, once at minimums on the electronic glide slope - or presumably once you have visual contact with the runway (RW commercial carrier pilots please feel free to chime in on the opinion of a private pilot) you can revert to the visual guidance system and drop below the electronic glide slope as long as you are on or above the visual system glide slope. 

 

Back to your point - I believe you are now seeing things as you should.  Not sure why this was not the case before.

Dan

Legacy Virtual Airline

Legacy Aviation Knowledge Academy

 

Windows 10, i7 3770 3.9 GHz, 16 GB DDR3 RAM, NVIDIA 1070 ti, 42" 1080p widescreen / P3D v5, P3D v4, FSX with Acceleration, FSX-SE / TrackIR-5

  • Author

Hi Dan!

   I am in agreement with everything you said and it should stand for reason that in order for the Visual lights to indicate in agreement with the GS signal (assuming the same approach angle) the VGSI would have to be positioned BEYOND the glideslope touchdown point since the eye position is 10-12 feet above the GS receiver.  Therefore the VGSI located BEFORE the GS TD point would indicate an ABOVE glide path when the GS is centered over the Threshold.

 

  For some reason, however, I was experiencing both paths coinciding over the runway end on "default" FSX runways and always found it necessary to correct the AFCAD's to agree with approach plates.  All default PAPI are placed 750 ft from runway end and VASI lights are always 900 ft from runway end on the FSX default AFCADS.

 

  I have had FSX for over 6 years and weathered two complete re-installs along with a complete reformat and OS change and always experienced the same coinciding paths on default scenery runways.  Suddenly I am not.  So some system file must have been modified since my complete reinstall of FSX has not brought back the default situation this time.

 

If you confirm that the height over the runway end (assuming no displaced threshold) on FSX standard default runways is indicating about 28-30 ft agl on YOUR system then I will gladly fix all the AFCADS I had previously edited and live with it.  Thanks.

I'll give it a shot - guess after all these years I'm going to have to learn how to use the slew function in FSX :blink: :O

Dan

Legacy Virtual Airline

Legacy Aviation Knowledge Academy

 

Windows 10, i7 3770 3.9 GHz, 16 GB DDR3 RAM, NVIDIA 1070 ti, 42" 1080p widescreen / P3D v5, P3D v4, FSX with Acceleration, FSX-SE / TrackIR-5

  • Author

Hi Dan!

   Appreciate your help.  "y" enables slew; "q" raises the plane; F1 drops it down (rather quickly).  

Well this is interesting.

 

The first set of screen shots are what I am used to seeing - at my home (major) airport KSAT, the most-used Rwy 12R.  As titled, they are On the PAPI, One Red above the PAPI and On the Electronic glide slope (all white on the PAPI).  Exactly as I expected - see the approach plate which shows the visual and electronic glide slopes are not coincidental.  http://skyvector.com/files/tpp/1312/pdf/00369IL12R.PDF

 

Yesterday I was flying "Foggy Friday" at EasternHops (http://easternhops.com/ - fly with them sometime, they're good fun and Foggy Friday makes for some challenging landings - you don't have to fly with the group; the whole world is fogged in on their server on Fridays) and we landed at KBOS - where the approach plate shows that the visual and electronic glide slopes are not coincidental (http://skyvector.com/files/tpp/1312/pdf/00058IL22L.PDF) BUT - on approach you can see that there is almost perfect agreement.  Displaced threshold, but this should have nothing to do with it since the touchdown points differ and are measured from the displaced threshold.

 

THEN - off to KORD where Rwy 27R does not show a difference between the visual and electronic glide slopes (http://skyvector.com/files/tpp/1312/pdf/00166IL27R.PDF) but the pictures attached do - one showing on the PAPI, the other showing on the electronic GS.

 

So in conclusion I guess, as amazed as the world might be about the revelation - Microsoft has not been completely accurate in depicting airports and their approaches :O - wow!  Might there be other issues yet to be revealed with FSX??  :P

 

None the less, I guess this shows that in some cases FSX does show you on the electronic glide slop but not on the visual glide slope - be that correct or not.

Dan

Legacy Virtual Airline

Legacy Aviation Knowledge Academy

 

Windows 10, i7 3770 3.9 GHz, 16 GB DDR3 RAM, NVIDIA 1070 ti, 42" 1080p widescreen / P3D v5, P3D v4, FSX with Acceleration, FSX-SE / TrackIR-5

  • Author

Good tests.  Your system is showing what my system is now, so whatever automatic update (happens when you are on the internet and it can happen quickly with just a flash notice) has also affected you.  Notice however that WHEN the VGSI and the GS are not in sync it is noted on the IAP and also shows BOTH crossing heights.  For KSAT 12R FSX has it backwards!   The crossing height for the PAPI should be 75 ft whereas the GS is 58 ft (both agl).  Your image shows the opposite (that the PAPI crossing is 25 feet lower!).  To correct this, the PAPi would have to be moved considerably down the runway toward the center.

 

Now at KBOS 22L, the PAPI is located past the runway touchdown bars to the point where it coincides.  Most FSX defaults, however, have ALL PAPI placed BEFORE the touchdown so it stands to reason the TCH would be lower.

 

This  really makes sense since the eye height to observe the PAPI is 14-20 ft above the GS receiver so in order to coincide the PAPI would have to be placed further down the runway than the GS transmitter.  I am testing this at 1300 feet from runway end for a crossing of 52' agl which is standard GS path and it seems 1350 works for a 55' TCH.

 

I always knew that PAPI placed BEFORE the GS transmitter should NOT coincide with the GS but for some reason they always had for me in FSX so I just went with the program.  Back when I flew commercially, PAPI were rare, mostly VASI and they were not allowed to be used below 200' agl since they were too inaccurate.  PAPI, however, can be used right down to touchdown if they are in sync and most are being adjusted that way unless otherwise noted for terrain reasons on the IAPs.

 

I now only fly my C172 around locally in Florida and most small airports do have PAPI now but only a few have ILS so I didn't pay much attention except that PAPI was always located FURTHER down the runway and when they didn't coincide, I was always getting REDS when on the GS, never WHITES (RW) as in FSX.

 

Again, thanks for confirmations.  Amazing that this FSX discrepancy error has never been addressed before on these forums.   

To add a bit to the confusion is that it is my impression (and I am aware that my set-up - screen size and position, use of wide view aspect = true, zoom percentage, etc influences what I see) is that compared to my RW perspective when I am on the visual GS (determined by PAPI, VASI, whatever) according to the sim it is not look quite right compared to what looks right based on my RW perspective.  I have always attributed this to how things in a 2D world trying to mimic a 3D world end up looking but maybe you have discovered a more fundamental flaw that explains this incongruity.  None the less I have always found it pretty amazing that $30 worth of software replicates the experience to the point that it is at least an enjoyable diversion - and precise or not, replicates to a great extent the real thing in spite of some aspects possibly being a bit skewed.

 

I have always had the same VASI vs electronic GS difference and have updates turned off (now on Windows 8 and had already gotten the word that auto-updates were messing things up so never had updates turned on and never load updates).  This has been true for my first (XP) sim computer, current systems running Windows 7 and now my (never updated) Win8 setup.  Still seems odd that there was a change for you.  Something else you did in those two weeks between then and now?

Dan

Legacy Virtual Airline

Legacy Aviation Knowledge Academy

 

Windows 10, i7 3770 3.9 GHz, 16 GB DDR3 RAM, NVIDIA 1070 ti, 42" 1080p widescreen / P3D v5, P3D v4, FSX with Acceleration, FSX-SE / TrackIR-5

  • Author

Hi Dan!

 

   I sure appreciate your diligence.  This probably isn't even noticed by the majority of simmers.  I guess I am getting a little OCD in my old age! lol!  But your comments and observations are indeed insightful.

 

   BTW,  I also tried turning off Wideview and experimented with every combination of view % and heights of cockpit, etc., but nothing would bring the lights back to what I was observing earlier.  The truth is after you and several others are now confirming similar experiences, I chalk it up to good fortune that now what we are seeing is more closely matching the error inherent in the default AFCADS.  I am patiently adjusting the runways for each airport that I fly to before activating FSX and finding that the GS transmitter on many of the airports is also located in the wrong position compared to the charts so I am fixing that at the same time.  It only takes of couple of minutes to make the adjustments before each flight and so far my estimates are garnering acceptable results.  Most simmers probably don't pay much attention to it and as you say it is amazing that an inexpensive program can provide such an immersive experience even for us who fly RW.

 

  FYI:   my results so far are that the GS transmitter moved slightly forward (toward the runway center) of the wide touchdown bars will yield a 51 ft TCH and setting the PAPI4 to 1250 ft (vs FSX setting of 750 ft) from the runway endpoint will sync the two glide paths.  For a 55 ft TCH requires the GS to be moved further forward (trial and error) and a 1350 ft displacement for the PAPI4 from the end of the runway puts them in sync.  That's all I have found so far but most TCH are in that range worldwide with an occasional interpolation as needed.  An exception, of course, is your KSAT setup.  But notice that both crossing heights are given on the chart and that the PAPI TCH is ABOVE the GS (not below) so a little tedious trial an error could fix the FSX KSAT AFCAD to correctly depict the 12R setup.  

 

   It is a rewarding experience when 'what you see' on the charts is 'what you get' in the simulator on approach! 

 

   And I, also, have noticed that the view can be somewhat unrealistic in some of the commercial models and sometimes takes trial and error manipulation that most often acquiesces to compromise at best!  Still beats the price of AVgas!  (or Jet A!). 

Create an account or sign in to comment

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.