On 5/15/2021 at 4:40 PM, rog943 said:

However It does still leave the question of what the HSI deviation setting actually is and what it might do - either lateral or vertical.  Shall I leave both at 1.0? 

This is detailed in the RXP User's Manual, but in short, there are a few 3rd party aircraft/gauges which are not "scaling" the needle deviation as you'd expect. For example a 1 dot deviation is showing as 1.27 dots (those of you astute with the SDK understand what I'm referring to with these values).

The best way to use this setting is simple: during the device POST, once on the instrument check page, validate the HSI and/or VOR are showing 1/2 deviations (vert + horiz). If they don't, use the scaling factor to adjust their deviation back to 1/2, and you're done!

Thanks Jean-Luc.  I don't think that applies to mine. The GTN750 is a great addition to my equipment.

Thanks for the help.

Roger

On 5/15/2021 at 4:55 PM, RXP said:

The DI heading is geo-magnetic and can deviate (calibration needed)

The TRACK is True +- the mag var from the GPS database.

In practice, both the sim and the gps are using a mag var model and there could be small discrepancies between the two which can lead to up 2 deg truncated values difference as explained above and is normal (at least in the sim). IRL, the magnetic sensor and the GTN mag var model could have a small difference as well theoretically.

Actually, can someone with a real GTN confirm they are not always matching IRL?

Are you sure the database is programmed with true tracks? That would indeed need a mag var model in the GTN for all procedure calculations, which seems to me overcomplicated,

I would expect they are programmed magnetic, as published charts are generally magnetic referenced. Then it would not need a mag var model. The heading information is coming from the heading instrument, generally slaving a magnetic sensor in either the tail of the aircraft, or in one of the wings.
The magnetic track information comes from the GPS including a mag var model, which I think comes from the GPS global system itself, and thus is always up to date. No recalculation on database values required in that case.

 

Here is what I know about this:

The GPS navigation and computations are all done in True. The GPS constellation signal is only a clock signal. It is in triangulating the clock signal value and the clock value from at least 3 GPS that the system can determine the intersection of the 3 and the position (with error margin).

The Mag Var model is hard-coded in the GPS software but it is also included in the DB files, therefore can be updated from time to time. All Mag indications are based on the True source value and the Mag Var model.

If you connect a Mag Heading source or you feed the Mag Var from an external device, it is not used everywhere the same. In any case though, our implementation is taking care of this as much as possible but due to the nature of rounding errors there still can be some slight discrepancies comparing just readouts values.