Guys, if you look a tiny bit closer into the whatabouts of GPS, you’ll find a lot of useful documentation in the net, such as, which signal strength do different GPS receivers and their antennas still pick up, and how do they deal with errors, and do they give you a warning below certain error correction thresholds, and so on and so forth. Satellite signals aren’t really strong, and get deflected pretty easily, especially in the mountains. Horizontal resolution of most GPS devices nowadays is pretty good. Which is why you will see, in most cases (preferrably with no mountains around you), that you’ll be exactly where that purple skydemon or jepp vfr line shows you are. Signal correction and interpretation for vertical position / altitude is generally more difficult, and not usually the prime focus for devices that in principle are designed to show you the way to the next McDonalds….. So, using an iPad inside a cloud to determine whether the mountain in front of you is low enough ?
Hmm….
stevelup wrote:
The SD terrain safe mode is superb and I was baffled when I saw your screenshot. Took me a minute to figure out what was going on.Try changing to SkyDemon 2 chart format where things look as you would expect.
Do you mean that Terrain Safe doesn’t work in other chart formats?
It is a major (I think) issue with SD that the “Chart Formats” are not just formats but also feature/function packages. So some SD functionality wont work depending on the chart format. But I wouldn’t have thought Terrain Safe was one of them…
Obv the arc second size of latitude stays the same whereas the size of longitude decreases with cos(lat in degrees).
So around the alps 4.9 arc seconds is an approximate 150m x 103m.
You need to separate terrain from airports. That terrain resolution doesn’t mean that airport runways in the database can be 150m out of position. Airports and runways are at their actual GPS location and within the terrain databases there is actually an airport terrain database which is not higher resolution but is apparently somehow processed differently so the terrain around an airport looks right and presumably matches the airport elevation etc.
But even with SV you need to be careful about airport locations. On the runway at Vilshofen the SV showed me off the runway to the right. Landing using that in 0/0 would land you into the hill or perhaps on the road parallel to the airport. There is a large hill to the north and either that affected GPS accuracy or there is a database error. I think the former. I love synthetic vision as an aid but it is not an actual approach type and people should be under no illusions that it is more.
Peter wrote:
So, 10 arc seconds is a horizontal resolution of 300m (1000ft). I wonder how big a mountain peak could be contained within that?Even the 4.9as resolution puts SV into a category which I am sure would surprise most people, some of whom believe you can do a zero-zero landing just with SV.
This is meaningless. Free data is available “everywhere”. For instance, for Norway the free terrain data sets come in two version. One is 50*50m resolution and one is 10*10m resolution. For “terrain awareness”, 50*50m is more than enough. The accuracy in altitude is +-4m and +-2 m respectively. At 100 knots, each of those 50*50m tiles pass by you each second. With the 10*10m resolution, 5 passes by each second.
Just to put this even more into perspective. Consider flying at a 500 ft AGL (150 m), and your “cone” of downward vision is 30 degree on average. At 50*50m resolution you will at any moment “cover” 100 tiles below you that you cannot see, each with an accuracy of +-4m. At 10*10, you will cover about 2500. Another thing is surface structures. Even at 50*50 you will run into problems with taller buildings, and even trees, since their height is comparable to the resolution in length and width, not to mention the accuracy in alt.
4.9 arc seconds may seem a bit rough, but that is only due to a “naive” view. It is the accuracy of the altitude at any given point on the surface that counts. 3 and 1 should be more than adequate for 50 ft low level flying, considering no surface structure (trees, buildings, power lines etc etc). The main point is, you can build “tactical” databases any way you want to get the functionality you want. Lets say you start with raw 10*10 data and “down sample” to create “4.9 arc second” accuracy data set. You wouldn’t just average everything in a structured grid. You would build an unstructured grid by using arbitrary sized triangles, then only use as many as to maintain the accuracy of +-2 m in altitude, or anything appropriate accuracy. I mean, even +-10 m would be way more than what is practically needed, given the effect of surface structures. You could also build it so that no point within any given triangle is lower than the raw data + the accuracy of the raw data. A rough terrain requires lots of tiles (but still only a fraction of the raw data), but a smooth undulating terrain requires almost no tiles at all. Water is flat for instance.
The ancient G1000 probably use a naive structured grid for all I know. Newer 3D hardware all use unstructured grid and arbitrary tiles per default.
So around the alps 4.9 arc seconds is an approximate 150m x 103m.
In that case I find it hard to understand what I heard from one SR22 pilot who told me he used SV (panel mounted) to do zero-zero approaches into grass strips.
I can see it working to a proper airport, because the SV scenery must be tweaked to be right as per the airport diagram and elevations (otherwise people would demand money back as soon as they landed somewhere 
) but some grass strip could have its 3D contours 100m off.
This isn’t google imagery which is a lot more accurate. This is a database of under 1GB sitting in the box in the panel.
It would be interesting if anyone knew how the blending is done to make SV look right at airports.
It would also be very interesting to know how “peaky” terrain is treated, because ~ 100m laterally could hide a huge vertical spike. I would guess (hope!) they would store that as a cube with a 150×100m base whose height is at the maximum elevation within that 150×100m rectangle. This is what Jepp got wrong in Flitestar and the colour coding in their old MFDs such as the KMD550 – they averaged the height of several adjacent cubes, which will always produce an under-estimated elevation!
Free data is available “everywhere”.
For instance, for Norway
Exactly
Then you need to reverse engineer the GPS terrain database and manipulate the “free data” into that and find a way to upload it.
One can download free data. For example a few years ago I downloaded about 50GB from google terrain – to produce the topo maps for the Alps and the Pyrenees, for overflying above cloud. This then condensed to 5GB for display in Oziexplorer. High-res scenery – probably a lot better then 100m. But these sources dry up. OSM dried up years ago and google followed. They all try to block bulk downloads. But this is relevant only to a totally DIY solution, where you develop the SV viewer also.
Peter wrote:
In that case I find it hard to understand what I heard from one SR22 pilot who told me he used SV (panel mounted) to do zero-zero approaches into grass strips.
Maybe he meant in combination with the FLIR that many SR22s have…that seems more feasible…
Peter wrote:
But these sources dry up
The distribution point maybe, but not the source itself, the main source. The main source is not interested in others copying and distributing the data for several reasons.
Peter wrote:
But this is relevant only to a totally DIY solution, where you develop the SV viewer also
These are public and official data, only in “raw” form. I would think all users of raw data would transform the data in some way, suitable for the particular application. For instance SD, only God (or the Demon) knows what format the data is in, to get a good overall user experience and adequate resolution and so on.
AnthonyQ wrote:
Peter wrote:
In that case I find it hard to understand what I heard from one SR22 pilot who told me he used SV (panel mounted) to do zero-zero approaches into grass strips.
Grass and even water runways appear in SV.
Maybe he meant in combination with the FLIR that many SR22s have…that seems more feasible…
Feasible, yes. Advisable, certainly not.
That all sounds rather theoretical, LeSving. Is there a product out there which uses this “free data” to generate an SV presentation usable in flight?
Maybe not the place to ask, but what seems to you the most effective, in terms of avoiding CFIT: Synthetic Vision or TAWS ?
