My point was that altiport runways have only one threshold.
I did have that spot on – do check the original thread. From Dave Philips’ posts it appears that one cannot simply assume that a real ILS GS should be replicated.
There was no attempt to replicate a GS. It was more akin to a +V pseudo GP, with a geometric straight line to a point in space at an angle determined by the database. If the threshold elevation was correct, then the GP had to go there.
What the author of the app never worked out was how to determine, on a case by case basis, whether the vertical model on the particular Android phone, with its particular Android version, and its particular setup, took into account WGS84 or not. The database contained an entry for the geoid at each runway end, and that was accurate to the foot. Generally it was a mean between two local geoid variations from published entries on opposite sides of the runway (eg East Mids and Doncaster for Northampton). In doing that exercise, I unearthed quite a few geoid errors in the AIP, and got them corrected.
I have trialled GPS ILS on a lot of phones and never found one that was not accurate once the geoid switch had been set properly. That you did find one does not hugely surprise me, but it is not right to say that the GP was wrong. It was wrong on your phone, for whatever reason. That is the way with uncertified software on uncertified equipment.
I wonder how Tim Dawson compensates for geoid on the Android version of SD. Maybe one of the reasons that he stops GP guidance at 500’ is because he cannot be confident that he has got it right. (Geoid error is typically in the range +/- 100’ usually much less).
(Edited to add that I have remembered that that was not how I did the geoid correction. Geoid is published online for every latlong, and I used that, but cross checked it for gross accuracy against nearby airfields which published geoid error. That’s how I discovered the errors I did. I put a huge amount of work into that database.)
I think that Dave’s comments about ILS GS are related to a misunderstanding, created by the name of the app, that it has anything to do with ILS (in the VHF/UHF sense). It is analogous to the “ILS” in SD and “Visual Approach” in GTN.
GPS ILS was way ahead of its time when it was produced. History has shown that the concept was good, but equally has improved on it, not least by having it based on certified aviation databases rather than hard grunt work. But I am quite confident that every line in that database was correct last time I worked on it.
The geoid error can be fixed for say the UK where it is about 160ft. Every non-aviation GPS I have seen has roughly the same error, except for the older SIRF-2 chips which had a separate issue.
Perhaps the app should not have “ILS” in its name, because the GS it presents is not aligned with an ILS GS where an ILS IAP exists, but it does have that name…
Geoid correction is normally done with a lookup table and interpolation. There is a long polynomial which will also do it but it doesn’t work outside certain latitudes IIRC. IFR GPSs, and the better aviation handhelds like the Garmin 496 and above, use a lookup table AFAIK.
The one interesting thing I learnt is that WAAS/EGNOS doesn’t help with this stuff. It just gives you a better lateral accuracy. It doesn’t “fix the geoid”. The WAAS/EGNOS handhelds are thus no more accurate for altitude.
When I did it, there were many geoid corrections around 80’, but I don’t remember the details.
It is not right to say that Android, at least at the time, returned an elevation that could be relied on to correct or not correct the geoid. There appeared to be no rhyme nor reason to it. You just had to check once (by standing at a known elevation) and either flick the switch or not until the correct altitude was shown.
It isn’t android; it is the GPS chip mainly. Android is just an OS.
Geoid correction is not done by any GPS chip AFAIK. It is done separately in software. Does an IOS device have geoid correction, for the whole earth’s surface? The Ipad2 we have and the Iphone 4 we used to have, didn’t. It was about 250ft out where we live.
Peter wrote:
It isn’t android; it is the GPS chip mainly. Android is just an OS.Geoid correction is not done by any GPS chip AFAIK. It is done separately in software.
Those two sentences don’t make sense to me. Surely the OS is software? Anyway, I am showing my ignorance of the inner working of the software. All I can tell you for sure is that some phones needed the switch one way, some the other.
What I meant was that the GPS chip does an incomplete job, so software external to it is needed for the altitude to be corrected.
Consumer products are mostly designed “for finding the nearest McDonalds” so they don’t bother.
Actually I am not sure if any moving map app on any consumer device does proper geoid correction. A lot of the ones I have used do have an “altitude calibration” function whereby you can trim out the usual (in the UK) ~150ft error, but that works only in the UK. When I do a flight UK to Greece for example, I see this in the movies which have the GPS data as a subtitle. The same GPS needs about 160ft in Brighton and something like 200ft on Crete (to show the correct runway elevation). The subtitle conversion program I use (NMEA to SRT) has a command line parameter for this. But if I flew nonstop Shoreham to Crete (not really possible except with a massive tailwind) I would not be able to correct both ends at the same time!
