The relative terrain is fantastic! I use it very regularly for finding the best way down a valley or over a mountainous range (in a helicopter).
However, there are times when the difference between my height and the cloud base and also the potential low points in the mountains are so similar in height that it all just shows up red and the potential through-route is not shown even if it's clear.
I therefore have a question and a request:
What are the threshold height differences for the colours to change to red or yellow?
Would it be possible to add a feature so that we can edit these thresholds? Ideally I would have it so that only things higher than me are red so that it shows even the smallest gap
Andrew, the thresholds are set at 500ft and 1000 ft, so in flight anywhere with less than 500ft of air below you will be red, and anything with more than 500 but less than 1,000will be yellow.
Are you familiar with teh use of the function in planning mode? There you can instead select "valley terrain" and select a reference elevation (in effect a simulated aircraft altitude) in 500ft steps to see the map coloured in the same 500 and 100ft bands relative to the selected reference elevation.
While in principle I suppose it should not be difficult to provide user-defined limits, it could introduce the risk of someone flying dangerously unaware that he had temporarily re-set the limits. That's something we have to think seriously about before we make something user-configurable.
For fixed-wing flying I think 500 and 1000 are sensible levels to use, but for helicopter flying I can see there may perhaps be a case for being able to work to tighter limits - though we need also to consider the error sources for GPS altitude indications, which are always greater than horizontal position error, and might approach 100ft.
Might it be helpful to retain the current settings but perhaps show any terrain above your altitude as black?
Some good points there, Andrew. To pick up on a few of them:
From memory the terrain data is form teh NASA STRM database which is on a grid spaced at about 30m intervals. The NASA dataset I think may provide highest and lowest elevation in each grid cell, but we use just the highest. Generally it is pretty good, but there may be some "voids". I'm not sure what the vertical resolution of the data is but if you look at the profiles presented in the VPV you will see there that to achieve adequate processing speed EasyVFR uses quite a coarse vertical resolution (about 125 ft steps IIRC. I suspect the same limitation applies to the relative terrain colouring. Of course there is also the issue of trees and other obstacles to consider. The NASA data is intended to show the ground level but there may be a dense forest reaching up to 200ft above that, and also any buildings, towers, masts, pylons, etc, under 300ft above ground level are not included in our database.
As regards vertical accuracy of GPS output there are 3 issues to consider.
Firstly, GPS does not directly calculate altitude above sea level, instead it calculates altitude above a spheroid that does not match sea level exactly. The difference between the two datums varies over the whole surface of the earth by about +/- 280 ft. This variable offset is called "GPS Separation"(Google that for the full story!). Many GPS chips contain a mathematical model of this offset and automatically apply a correction for it, so that their output IS an altitude relative to Mean Sea Level, but not all chips do that, and in general there is no agreed "flag" the chips set to say whether or not this correction has been applied. I think there have even been cases of devices being sold where manufacturers have used chips from different suppliers and some have done the correction and others have not!
Secondly, atmospheric conditions can cause minute variation is the speed of light which can therefore very slightly delay, or very slightly speed up the time teh satellite signals take to reach the GPS. And as the position is calculated based on the time taken by the signals to reach the GPS, this results in errors. As all the satellites are above teh GPS, any conditions that delay the signal cause the GPS to under-estimate its altitude, and if the conditions make the signal travel faster the GPS will over-estimate its altitude. The effect is not big but certified aviation GPSs have a facility to make corrections for this using data broadcast by the satellites which gives correction factors based on very precise measurements made at ground stations. But the GPS chips in phones and tablets do not have this capability.
Finally (within the limitations arising from the above two issues), GPSs measure true "geopotential" altitude (effectively the altitude that a very long ruler would measure!) However, airspace bases and tops are not defined in terms of geopotential altitude, instead they are defined in terms of pressure altitudes as would be measured by a barometric altimeter. Variations in air density due to pressure, temperature or humidity can cause very large differences between geopotential altitude and pressure altitude. This does not matter while all aircraft manage their cruising levels based on barometric altimeters - an airspace labelled as having its top at 2,000ft will actually have its top at an altitude where the pressure on that day equals the pressure that would exist at 2,000ft on a day when the atmospheric conditions exactly match the International Standard Atmosphere, and likewise a barometric altimeter will read 2,000 ft when subjected to the pressure that would exist at 2,000ft on a day when the atmospheric conditions exactly match the International Standard Atmosphere. So the altimeters in every aircraft will read 2,000 ft when at teh top of that 2,000ft airspace, even though, in practice, the actual (geopotential) altitude might be several HUNDERD feet above or below that. (This, of course DOES NOT impact teh accuracy of GPS indications versus terrain elevation, because terrain elevation is not expressed in pressure altitude but in geopotential altitude.)
The "Altitude Calibration" feature in EV3 that you mention was primarily provided to ensure that EasyVFR was using an altitude that corresponded to what an altimeter was displaying so that EasyVFR could give a precise correspondence with airspace floors and tops. However, in practice few pilots actually use that facility and even fewer understood teh issues it was intended to overcome so the feature has not been included in EV4. Instead in Menu>System>GPS Settings there are two adjustments, one for GPS Separation ("AMSL/Geoid correction") which should be left at zero if your device already automatically makes this correction, but which in the UK you would need to set to about 180ft (depending on exact location) if it does not. If you fly more than about 1,000 miles form your normal base you might need to make a small further adjustment. The second adjustment there is "Calibrate AGL to zero" which provides a simple. quick way to apply an offset to make teh altitude used by EV to correspond to the altitude on the terrain database if you are on teh ground. Nether of these corrections can adjust for the difference between geopotential and barometric altitude (instead, EV4 just uses very broad safety margins when alerting about possible airspace penetrations.
Overall I can appreciate the attraction of knowing where the ground is "higher than you" but when all the tolerances, uncertainties and unknow obstacles are taken into account, most of the areas shown as less that 500ft below you could, on a bad day when all the random errors act in the same direction, be higher than you! At least in a helicopter proceeding cautiously you can slow down and grope your way forward or stop and turn back; a fixed wing pilot following a valley and being surprised by higher-than anticipated ground immediately ahead my have no option but to climb at max rate into IMC and hope he is outclimbing the terrain.
VBR
Stu
Thanks for taking the time for a comprehensive response.
I teach this subject and on a regular basis I encounter a bit of a problem in that after an explanation similar to the above, we then go and fly and actually use the technology in the real world and we experience a GNSS accuracy that is disappointingly similar to using a local QNH and is also very consistent during the flight. Typically using a new and decent quality tablet or phone we are never more than 100' out from the altimeter and when we land at a known spot height, the GNSS data is usually more accurate than the altimeter and so more reliable for terrain clearance.
I have flown all this week and taken particular note of the correlation. I was using the Garmin unit in the a/c (using a USB GNSS "mouse"), my phone just in a holder on the screen and also a tablet fed from a Pilot Aware mounted on the dash). I checked the data as frequently as I could during about 18 ish hours total time. Some of this was low level, all during daylight but both IMC and VMC. The longest sector was 90 minutes. The largest observed discrepancy between them all was 89'.
The Garmin unit has the facility to interrogate the GNSS data being used so I randomly took a photo of this screen to show the altimeter/GNSS discrepancy at that particular point in time (below).
This Garmin unit has a terrain warning screen which uses 1000' for the yellow section and 100' for the red and we use this feature frequently in this aircraft.
I used to make use of the alt calibration feature on EV3 on most flights as it keeps the airspace warnings relevant. On EV4 I find myself using the geoid correction as an alternative and once set it seems to remain correct for the rest of the day.
Hopefully all this will help you come up with the best solution for EV4.
Would it be possible to add a feature so that we can edit these thresholds? Ideally I would have it so that only things higher than me are red so that it shows even the smallest gap
I'd like to re-start the conversation particularly regarding the above.
I've been flying many times with EV4 recently in terrain mode and using it to help safely negotiate through the mountains when the cloud is 'hanging' on the tops.
If we approach the hills lower than the surrounding tops but also lower than the saddles down the valley, everything just shows red. It's hard (but not impossible to guess) where the lowest crossing points are. Having a colour differential to show ground HIGHER than the aircraft would really help with this. Or maybe within -100' and higher to account for GNSS data tolerances. I realise that this might not suit fixed wing operations so maybe this could be made an editable setting? OR changes when a helicopter profile is selected?
All the times I have tested (380 hours in the past year), the GNSS data is within 50' of the local QNH which is amazing considering the technology!
Hi Andrew,
I see what you mean, but its not only the GNSS accuracy, its also the terrain elevation data accuracy that is at play, that is greatly impacted by void-fixing algorithms applied to the various datasets available. Last but not least also lateral offsets of a few tens of meters (up to a hundred meter is also not uncommon) caused by dataset-, void-filling and render approximation errors is well possible.
I fear when we would colo(u)r only terrain higher then the current plane's GPS altitude we would get overwhelmed with "bug reports" showing "wrongly colo(u)red terrain when compared to actual situations, having to explain how all the various uncertainties can end up in these results.
Yes I see the issue.
Part of the problem I guess is that some of the hills in question are max 2000' and the lowest crossing points/saddles are around 1200' (so barely hills!) With cloud around 1600' We fly towards them at 1500' ish. The whole map therefore goes yellow and the majority of it goes red so it's hard to find the low points. On the few occasions where the cloud permits a brief climb instantly removes loads of the red and reveals where the lowest saddles and valleys are, but then we are forced back down again and it returns to red again.
(I was in exactly this position yesterday getting home)
I notice there is a dark red sometimes showing. Does that mean anything in relation to height or is that terrain shading?
n.b For non-UK readers - we do not follow PART SERA 500' rule here.
The relative terrain shading red and Yellow is using gradients based on actual terrain clearance, so that is a possible indication. But the shading also has its effect, so I guess its not really usable for your situation.
Maybe by putting in some transparency for the first 500ft of red will better indicate those valleys. Let me play a bit, if that fails we can always reconsider to put in a user-selectable clearance value for Red and Yellow.