Device Connected but Device heading Differs from GNSS Heading from Dual Antenna INS

Posted by Will Dillingham on Aug 18, 2020 11:58:23 AM

Inertial Labs logo - new2-1


Purpose: Diagnosing a common issue where the device is connect but heading as seen by device differs drastically compared to the GNSS heading.

Last Updated: July 2019

Common Issues:

1. The antennas are connected, but the heading of the INS starts with 0 (relative heading).

2. The INS heading differs a lot from the GNSS heading.


For heading, the INS algorithm is using dual GNSS heading for heading correction only if the dual GNSS solution is valid. A valid solution is when "Angles position type" is satisfying. "Angles position type" is the GNSS position type at orientation calculation using dual GNSS receiver. "Angles position type" is satisfying when it reaches “Integer narrow-lane ambiguity solution”.

In OPVT2A output format 'Angles position type' value is located under the byte 85, and in OPVT2AHR it is located under the byte 113. If this value is less than 100, please see its description in the Table 6.17 of the ICD. If “Angles position type” < 100 then “INS solution status” is good, otherwise it is poor. The "Angles position type" can be observed in the INS GUI (when OPVT2A or OPVT2AHR output formats are used) - please see red ellipse on the screenshots below.

To get valid “Angle position type”, the antennas should be installed with a clear view of the sky. Also, it is generally recommended to install the antennas as high as possible, and in some cases it is necessary to further isolate the antennas with a grounded metal plate with at least 12 cm in diameter. The plate must be connected to a mass with large capacitance, like the vehicle or vessel body, to ensure that the plate is grounded.

If possible, it is recommended to use an antenna similar to that of the Novatel Pinwheel ( These antennas are much better at multi-path performance as a grounding plate is included with the antennas.

Also, it is important to shield all possible sources of RF interference, including USB3.0, as radio interference can cause serious degradation in signal quality.

Screenshot #1:

Angle pos. type = l1_float

In the case if angle position type is not "Integer", the INS algorithm does not take into the account the dual GNSS heading. Therefore, as you can see the GNSS heading was 62.15 deg, but the INS heading was 349.43 deg (GNSS solution were treated as not valid) and was computed using AHRS algorithm.

INS GUI l1_float

Screenshot #2:

Angle pos. type = narrow_int

Since the angle position type is "Narrow Integer", you can see that the INS heading was corrected using the GNSS heading.

INS GUI narrow int


Topics: Problem, INS, INS-DL, Heading

      Knowledge Base Documents