I do not know how GPS-ILS collates it’s data but I can tell you how we create a GPS database in the calibration world.
Firstly, it is important to note that you GPS position varies with time. In other words, if you accurately fixed your position on a particular day, you may find that it has moved some weeks/months later. The drift is minimal (laterally centimetres, vertically tens of centimetres) but it is an important consideration.
So, before we calibrate an airfield we undertake a site survey. We gather the following data for each system being calibrated: Threshold, GP, runway end, Localiser and DME. We also create a reference point, this being where our DGPS unit is placed whilst calibrating. In essence, we create a database where all positions are known relative to the DGPS unit giving a positional accuracy (relative to the DGPS) of less than 20mm. At this point we have little interest in our GPS position as derived from the satellites although the DGPS unit will not verify (ie confirm it’s location) if it is more than about 15cm different from the satellite derived position.
Site files – we use the database to create a site file. As far as glide paths are concerned, we calculate a position in space that is equivalent to the Threshold Crossing Height (given by the customer) at the threshold. From this point we create a line in space which follows the runway alignment (having used the threshold and end coordinates to ascertain alignment) and an accurate 3 deg GP. It is this line that we use as a reference to check the alignment of the ILS GP.
So, if GPS-ILS has a known TCH and both runway ends it can, in theory, mimic the alignment of an ILS GP. however, things are not that simple and we often find that we have to apply a vertical adjustment to our databases as things may wander.
Finally, we do calibrate some GPs where the angle changes throughout the year (by up to 0.15 of a degree), this being dependant on the density of the ground immediately infant of the GP antenna. It’s also worth noting that an ILS GP will never be a perfectly straight line as it is an analogue signal that suffers all the usual things such as refraction, reflection etc.
Peter,
It’s not FAF to MAPt, no. It’s a GP slope to the threshold. Generally, it will be, for example, a 3° slope drawn to end at the PAPIs.
As I say, I can give you and talk you through the database in detail.
Timothy wrote:
It’s not FAF to MAPt, no. It’s a GP slope to the threshold. Generally, it will be, for example, a 3° slope drawn to end at the PAPIs.
There’s a problem with that. The PAPIs are not coincident with the ILS GP. PAPIs are set-up using MEHT for the largest aircraft type expected to utilise the runway whereas the ILS GP is set to attain the necessary GP from TCH. MEHT and TCH are not necessarily the same number.
Here’s a good diagram
That is indeed a good diagram.
Peter wrote:
Somebody ought to tell the programmer of the GPS-ILS app to look into this. I tested the app at some UK ILS airports and while the LOC was spot on, the GS was nowhere near the real one (it was totally off scale at EGHH).
That’s interesting… On a recent trip on commercial flights, I had the SkyDemon ILS function active during the approaches, and it, too, was off and increasingly so the closer to the runway we got until it was off the scale.
That’s because the developer hasn’t fully thought through how an ILS GP is generated and how to replicate it.
I believe the SD pseudo-glideslope is referenced to the airport reference point, not the threshold of a particular runway. Good enough to get you out of trouble as last resort but not more than that.
dirkdj wrote:
I believe the SD pseudo-glideslope is referenced to the airport reference point, not the threshold of a particular runway.
The GPS-ILS reference point is the touchdown point, in 3D.
Thanks, I suspect, to input fron @Timothy, the GPS-ILS app seems to have come a long way since it was first mentioned on EuroGA.
However, I’m not sure how practical the “downhill” approaches at altiports such as LFJD, LFHM and LFLJ are, even for “training” in VMC. These and similar database entries which involve flight at significant negative height could perhaps be euthanised to make way for some more useful practice approaches.
It is not as if entries in the database preclude others. Each runway end occupies (from memory) around 30 characters of text, so there is nothing to be gained from removing some.
As soon as anyone takes responsibility for removing runway ends they are entering a world of editorship, or curation, that is not, in my opinion, their place to do.
But it’s a free app on an Android phone that simply informs you whether your current GPS position places you above or below, left or right, of a particular line in space. It comes with absolutely no warranty or suggestion that it has been surveyed or any thought whatsoever has been put into what would happen if you were to fly that course.
As an exercise for rainy evenings, I did undertake to edit the UK part of the database to check the exact position of every touchdown point, and the runway QDM, and I believe that I did it assiduously. If there is a mistake at EGHH, I could look at it.
But more to the point, the database is rather obscure when you first look at it, but it is completely comprehensible given a bit of briefing, and it would be very easy for anyone to change the record for one or more runway ends, either to suit their own preferences or, if they can convince the publisher that they are reasonably reliable, as I did, he will add the amendments to the database.
