The point of the thread is how can SD show us a relevant vertical deviation pointer and I highlighted why I felt that was not possible or could be confusing. It would be great if it could but I can’t see how without the added complication of an air pressure input. I think you’re letting your fascination with flight levels get in the way and hopefully my examples below will show why……I won’t make it more complicated by bringing temperature into it.



You’re flying along below transition altitude at 5000’ with a Qnh of 993 and SD agrees you’re at about 5000’. Without climbing or descending you pass into airspace that now puts you above transition level so you set 1013.2. What does your aircraft’s altimeter and SD now say? My guess is SD still says 5000’ but your altimeter now indicates about 5550’.



Alternatively, fly at FL80 from a high pressure area (1033) to a low pressure area (993). Is your physical distance AMSL always 8000’ and does SD show you at 8000’ at both ends of the flight? My guess is you’ve changed altitude by about 1100’ and SD will reflect this.



Everyone else feel free to ignore the following bit if you’re bored with our conversation as it’s a little off thread!



Work out the difference between two pressures and you can determine a height/altitude. An old fashioned altimeter does it mechanically and an ADC does it electronically. Both are in abundance, as can be confirmed by a quick look at many websites (Airbus, Boeing, Bombardier, Cesna, Embraer, Garmin, Piper, etc, etc, etc…). ADC’s are used regardless of the pressure setting, they don’t turn on/off dependent on transition level or standard being set. If you want any more help feel free to make it a private message so we’re not cluttering things up here.



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

How does the QNH reach the instruments... Hmmm. Good question. Pilot flicking the alt setting to standard? I think you'll find big iron (and small) were flying flight levels way before anyone thought you actually need an ADC to hold an assigned level. All it takes is a static port.

So how does that Qnh you've just been given reach your displays/instruments and autopilot? If you can find a way of doing away with ADC's then sell you're idea to Airbus & Boeing and you'll make a fortune.





So the point of my post is how can this be achieved so that the altitude we all work to is reflected by what we see on SD....the only way I can see is if there is a fluke of atmospheric conditions and even then you won't know it!



"Altitudes" are effectively pressure levels, it would be great if SD could show this but unless there is an air pressure input it can't display anything meaningful in this respect. At least with what we do have in SD there is a far more accurate idea of terrain and obstacle clearance than an old fashioned altimeter.



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

I think big airliners get around it by flying FL's above the transition altitude. Below the transition level no need for ADC either, you just crank in whatever QNH you're given. As far as I know, FL's are defined based on standard QNH, no need for fancy ADCs ...

Now in terms of altitude and QNH - obviously if the QNH (air pressure) changes, so does your altitude; but then again if the QNH changes you should be informed of it in principle...

Unfortunately I can't see how this can work in practise.



Correct me if I'm wrong but GPS can measure the actual distance between two points (e.g. sea level and the receiver) whereas our altimeters measure/assume our altitude by knowing the difference in two air pressures, the Qnh we give it and the pressure fed to it via our static source. Vary the Qnh and/or the air density and the two measurements are rarely the same.



I have no doubt which is likely to be more accurate but reality dictates we must use an altimeter to define our altitude and it's this that separates us from each other and any airspace infringements. Just because SD shows our level to be clear of an infringement either on "Plan" or "Mobile" it doesn't mean to say if we fly accurately to any V-Nav pointer that it will remain so. Big aeroplanes get round this by having an input from an air data computer so their VNAV Path is actually a pressure level but I'm guessing this is a little beyond Tim & the team?



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

I can confirm that we're seeing this here too, and it's do to with the specific way that runway data has been entered for Full Sutton. We'll release a hotfix build within a few days.

Just to confirm that I tried it om my simulator moded and the same happened, I got an unhandled exception (whatever that means, with these details) if they are any help.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.OverflowException: Overflow error.
   at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.DrawEllipse(Pen pen, Single x, Single y, Single width, Single height)
   at System.Drawing.Graphics.DrawEllipse(Pen pen, RectangleF rect)
   at Divelements.Aviation.FlyingInstruments.xf47137656ba6e9da.DrawForeground(Graphics graphics, Rectangle bounds)
   at Divelements.Aviation.FlyingInstruments.x51138fd5a5926dca.OnPaint(PaintEventArgs e)
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)
   at System.Windows.Forms.Nativewindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4952 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
SkyDemon
    Assembly Version: 2.1.0.15697
    Win32 Version:
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SkyDemon.exe
----------------------------------------
Divelements.Aviation
    Assembly Version: 1.0.4114.15695
    Win32 Version: 1.0.4114.15695
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.Aviation.DLL
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Divelements.SandGrid
    Assembly Version: 2.2.4.1
    Win32 Version: 2.2.4.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.SandGrid.DLL
----------------------------------------
SandDock
    Assembly Version: 3.0.6.1
    Win32 Version: 3.0.6.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SandDock.DLL
----------------------------------------
Divelements.Mapping
    Assembly Version: 1.0.4114.15695
    Win32 Version: 1.0.4114.15695
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.Mapping.DLL
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
SandBar
    Assembly Version: 1.4.3.1
    Win32 Version: 1.4.3.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SandBar.DLL
----------------------------------------
System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

 

Mr_rodge, you're not alone.
I also have the same problem with FS.

Simulated GPS on Plan:
If doing a Southerly approach, the Instrument view crashes when close to the airfield.

If doing a Northerly approach to runway 22, I get the same strange extended runway centreline as you did.

Could others try the simulated GPS approaches to ensure that mr_rodge & I haven't got corrupted installations?
(Did a fresh install of SkyDemon 2.1 prior to the tests)

Regards,

Max.

Hi nje,

That's the one.  Thanks!  I now have a totally different problem now though!  I'm using the 2.1 final.  See screenshots:

Not very clear, but it's 04 at FS, looks great.  Now for 22:

Now I'm pretty sure that's showing a north heading runway as 22.  Thing is, there is no such runway at FS, and it should be the same orientation as the first shot!  I coudn't for the life of me get the simulator to line me up with 22...

Help!  Cheers, mr_rodge.

Mr Rodge  I posted this on the 14th March, could it be my last paragraph you referring to?

I went on a short flight today from Hawarden to Woodford and used the new instrument view for most of the way. Groundspeed and altitude were spot on. Following the planned route was straightforward with the bug doing the business and the deviation line steering us in the right direction. We (my son flew into Woodford and I flew back) changed to the chart view about 5 miles out and routed to the extended runway and then switched back to the instrument view where the ils/glideslope kicked in.
We saw the distance to threshold appear and got the decent rate and lined up on the centreline. At 500 foot the glideslope disappeared and the ils line slowly moved accross to the left of the screen (wasn't sure if that was supposed to happen or not). It wasn't needed anymore at that point anyway.Well done SD team