Trimble/Applanix GSOF (Position) - 12

Driver to decode data from Trimble products using proprietary format GSOF (General Survey Output Format).

This includes most additional GSOF messages from Applanix AP+ units.

The following data can be decoded and stored from the different GSOF message types:

Positions
Headings
Motion (Roll, Pitch and Heave)
UTC Time
Angle and Speed vectors
Velocities, Accelerations and Rotations
Metadata (Status flags, Quality indicators, etc.)

Driver Information

Click to expand details...

Driver	Trimble/Applanix GSOF	Interface Type	Serial UDP TCP	Driver Class Type	Counted
UTC Driver	Yes	Input / Output	Input	Executable	DrvQPSCounted.exe DrvQPSCountedUDP.exe DrvQPSCountedTCP.exe
Related Systems	Network (TCP) - Trimble/Applanix GSOF (Angle & Speed) - 30 Speed Log Network (TCP) - Trimble/Applanix GSOF (Current Time #16) - 18 Time Synchronization System Network (TCP) - Trimble/Applanix GSOF (Heading) - 05 Gyro Compass Network (TCP) - Trimble/Applanix GSOF (Metadata) - 23 Miscellaneous System Network (TCP) - Trimble/Applanix GSOF (Position) - 12 Position Navigation system Network (TCP) - Trimble/Applanix GSOF (Roll Pitch Heave) - 03 Pitch Roll Heave Sensor Network (TCP) - Trimble/Applanix GSOF (Velo, Acc, RoT) - 42 Acceleration Velocity Sensor Network (UDP) - Trimble/Applanix GSOF (Angle & Speed) - 30 Speed Log Network (UDP) - Trimble/Applanix GSOF (Current Time #16) - 18 Time Synchronization System Network (UDP) - Trimble/Applanix GSOF (Heading) - 05 Gyro Compass Network (UDP) - Trimble/Applanix GSOF (Metadata) - 23 Miscellaneous System Network (UDP) - Trimble/Applanix GSOF (Position) - 12 Position Navigation system Network (UDP) - Trimble/Applanix GSOF (Roll Pitch Heave) - 03 Pitch Roll Heave Sensor Network (UDP) - Trimble/Applanix GSOF (Velo, Acc, RoT) - 42 Acceleration Velocity Sensor Trimble/Applanix GSOF (Angle & Speed) - 30 Speed Log Trimble/Applanix GSOF (Current Time #16) - 18 Time Synchronization System Trimble/Applanix GSOF (Heading) - 05 Gyro Compass Trimble/Applanix GSOF (Metadata) - 23 Miscellaneous System Trimble/Applanix GSOF (Position) - 12 Position Navigation system Trimble/Applanix GSOF (Roll Pitch Heave) - 03 Pitch Roll Heave Sensor Trimble/Applanix GSOF (Velo, Acc, RoT) - 42 Acceleration Velocity Sensor

System Interfacing

Click to expand interfacing details...

Message Types

Note that this driver will only decode and use data from the following message types:

Standard GSOF message types: 1, 2, 8, 12, 16, 27, 37

AP+ specific message types: 49, 50, 63, 64, 65, 66, 67, 68

It does also depends on the template database system setup whether one of the enabled message types are used or not.

Use the manufacturer's GUI to enable the specific output messages needed and its update rate:

GUI Example

There is no use to enable any of the other message types for this driver, but feel free to contact QPS if you do need decoded information from one of the unsupported types.

Timing

When your template setup has a valid Time Synchronization System (PPS) defined then the driver will time-stamp the observations using the decoded time from standard GSOF message type 16 (Current Time UTC).
Therefore make sure to enable message type 16:

Important is to set the update rate to 1 Hz
When your template setup does not have a valid Time Synchronization System (PPS) defined and/or standard GSOF message type 16 hasn't been enabled then the time-of-arrival (at the I/O port) will be used for time-stamping the decoded observations.

Database Setup

It is important to use the same interfacing settings for all 'Trimble/Applanix GSOF' systems in your template setup.

Click here to expand setup details...

Position Navigation System

Add a Position Navigation System to your template setup and select driver:

"Trimble/Applanix GSOF (Position)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Position)" when using the network interface.

The latitude, longitude and height observation can be decoded from:

Standard GSOF message type 2 (LLH)
One of the AP+ specific message types:
- 49 (Reference),
- 63 (Vessel),
- 65 (Sensor 1) or
- 67 (Sensor 2)
  which needs to be selected on the second wizard page.

First Wizard Page

Example serial interface

Second Wizard Page

Location
Select the correct antenna location that represents the position of the selected receiver number.
Receiver number
Important setting to select from which message the latitude, longitude and height observations and qualities (root mean square) should be decoded:
- REFERENCE
  Observations and qualities will be decoded from AP+ specific message type 49 and 50 (reference frame navigation solution and rms).
- VESSEL
  Observations and qualities will be decoded from AP+ specific message type 63 and 64 (vessel frame navigation solution and rms).
- SENSOR1
  Observations and qualities will be decoded from AP+ specific message type 65 and 66 (sensor 1 frame navigation solution and rms).
- SENSOR2
  Observations and qualities will be decoded from AP+ specific message type 67 and 68 (sensor 2 frame navigation solution and rms).
- 02
  Observations and qualities will be decoded from general GSOF message type 2 and 12 (position llh and sigma).
Horizontal / Vertical Datum
Select the correct horizontal datum that is applicable for the latitude and longitude fields.
Select the correct vertical datum that is applicable for the accompanying height field.
Both datums are always assumed to be on WGS84

The update rate of GSOF messages are configurable inside the manufacturer's gui and can be higher than 10 Hz for most messages.

For accurate positioning inside Qinsy a higher update rate is not necessary for the position specific messages and may even degrade performance, slowing down computations, increasing recorded database file sizes, etc.
By default the driver will limit the update rate of the positions to 10 Hz.
An advanced user may change this default limitation of max 10 Hz incoming positions by altering the value of the following registry key while offline:

Serial driver:
HKEY_CURRENT_USER\Software\QPS\QINSy\8.0\Drivers\DrvQPSCounted\Settings\GSOF MaxPosUpdateRate [Hz]

Network driver:
HKEY_CURRENT_USER\Software\QPS\QINSy\8.0\Drivers\DrvQPSCountedUDP\Settings\GSOF MaxPosUpdateRate [Hz]
HKEY_CURRENT_USER\Software\QPS\QINSy\8.0\Drivers\DrvQPSCountedTCP\Settings\GSOF MaxPosUpdateRate [Hz]

Entering a value of 0 (zero) means all incoming positions will be decoded.

The default limitation only counts for positions, all other observations (roll, pitch, heading, velocities, etc) are decoded without any restrictions.

Gyro Compass System

Add a Gyro Compass System to your template setup and select driver:

"Trimble/Applanix GSOF (Heading)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Heading)" when using the network interface.

The heading observation can be decoded from

Standard GSOF message type 8 (Velocity), type 27 (Attitude)
One of the AP+ specific message types:
- 49 (Reference),
- 63 (Vessel),
- 65 (Sensor 1) or
- 67 (Sensor 2).
  This source needs to be selected on the second wizard page.

First Wizard Page

Example UDP network interface

Second Wizard Page

Unit must be 'Degrees'.
(Note that for some message types the heading is published using radians but here you always need to select degrees)
Slot number 1
Important setting to select from which message the heading observation should be decoded:
- REFERENCE
  Heading and quality (rms) will be decoded from AP+ specific message type 49 and 50 (reference frame navigation solution and rms).
- VESSEL
  Heading and quality (rms) will be decoded from AP+ specific message type 63 and 64 (vessel frame navigation solution and rms).
- SENSOR1
  Heading and quality (rms) will be decoded from AP+ specific message type 65 and 66 (sensor 1 frame navigation solution and rms).
- SENSOR2
  Heading and quality (rms) will be decoded from AP+ specific message type 67 and 68 (sensor 2 frame navigation solution and rms).
- 08
  Heading and quality (velocity flag) will be decoded from general GSOF message type 8 (Velocity).
  The heading computation for the Velocity (type 8) message is derived from consecutive positions.
- 27
  Heading (Yaw) and quality (variance) will be decoded from general GSOF message type 27 (Attitude)
  The heading computation for the Attitude (type 27) message is computed from the moving baseline vector and requires a two-antenna system.

Pitch Roll Heave Sensor

Add a Pitch Roll Heave Sensor to your template setup and select driver:

"Trimble/Applanix GSOF (Roll Pitch Heave)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Roll Pitch Heave)" when using the network interface.

The motion observations can be decoded from:

Standard GSOF message type 27 (Attitude)
One of the AP+ specific message types:
- 49 (Reference),
- 63 (Vessel),
- 65 (Sensor 1) or
- 67 (Sensor 2).
  This source needs to be selected on the second wizard page.

Note that a heave observation is not available in standard GSOF message 27 (Attitude) or AP+ specific message 49 (Reference Frame).

A heave value is only available in AP+ specific message type 63 (Vessel), 65 (Sensor 1) or 67 (Sensor 2).

First Wizard Page

Example TCP network interface

Second Wizard Page

Select the correct Node location.
This will be the node location that represent the frame for the selected Slot.
Slot
Important setting to select from which message the motion observations and qualities (rms or variance) should be decoded:
- REFERENCE
  Roll and pitch will be decoded from AP+ specific message type 49 and 50 (reference frame navigation solution and rms).
- VESSEL
  Roll, pitch and heave will be decoded from AP+ specific message type 63 and 64 (vessel frame navigation solution and rms).
- SENSOR1
  Roll, pitch and heave will be decoded from AP+ specific message type 65 and 66 (sensor 1 frame navigation solution and rms).
- SENSOR2
  Roll, pitch and heave will be decoded from AP+ specific message type 67 and 68 (sensor 2 frame navigation solution and rms).
- 27
  Roll and pitch will be decoded from general GSOF message type 27 (attitude).
Sign Conventions
Make sure to use to following (Applanix) sign conventions:
- Roll: Positive heeling to starboard
- Pitch: Positive bow up
- Heave: Positive downwards
- Rotation Measurement Type: HPR (roll first)

Third Wizard Page

You may leave all parameters at their defaults

Time Synchronization System

Add a Time Synchronization System to your template setup and select driver:

"Trimble/Applanix GSOF (Current Time #16)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Current Time #16)" when using the network interface.

Time will be decoded from:

Standard GSOF message type 16 (Current Time UTC)

First Wizard Page

Example serial interface

Second Wizard Page

Note that the Time tag (GSOF message type 16) is always coming shortly after the PPS pulse (5-20 ms), therefore you may leave the Time tag - Pulse matching set to 'Automatic Matching'.

Notes

Make sure to enable message type 16; the current UTC time will be decoded from this message:

Important is to set the update rate to 1 Hz.
This type 16 message contains a value for the GPS week number, the GPS week seconds and a GPS to UTC offset value (aka leap-second).
The message will also contain two status indicators: the first one indicates if the time is valid and the second one indicates if the reported GPS to UTC offset is valid.
Qinsy will only accept and use the decoded time when the first status indicator is okay.
The driver converts the GPS time to UTC time and for this it will use the GPS to UTC offset but only when the second indicator is okay.
If this second status indicator is not okay then the UTC to GPS correction from the template database setup will be used.
Use a Time Synchronization Display to monitor this system while being online.
For easy monitoring you can see the decoded values formatted as a text string in the status column of this display.

Speed Log

Add a Speed Log to your template setup and select driver:

"Trimble/Applanix GSOF (Angle & Speed)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Angle & Speed)" when using the network interface.

Speed log observations will be decoded from:

standard GSOF message type 8 (Velocity)
one of the AP+ specific message types (49, 63, 65, 67)

These observations can be used to enhance the results of the kalman filter in the Qinsy computation setup

First Wizard Page

Example serial interface

Second Wizard Page

Add the required observation types that you want and select for each one the location that represent the frame for the selected Slot 1.
Note that from the listed observation types only the Angle, Speed and Vertical Speed types are supported, the Bearing (True) type observation is not supported.

You may change the default name for each observation as long as it doesn't exceed 16 characters.

Important is to select for each observation the Slot 1 Id which defines from which GSOF message the observations will be decoded:
- REFERENCE
  Total Speed, Down Velocity and Track Angle and qualities (rms) will be decoded from AP+ specific message type 49 and 50 (reference frame navigation solution and rms).
- VESSEL
  Total Speed, Down Velocity and Track Angle and qualities (rms) will be decoded from AP+ specific message type 63 and 64 (vessel frame navigation solution and rms).
- SENSOR1
  Total Speed, Down Velocity and Track Angle and qualities (rms) will be decoded from AP+ specific message type 65 and 66 (sensor 1 frame navigation solution and rms).
- SENSOR2
  Total Speed, Down Velocity and Track Angle and qualities (rms) will be decoded from AP+ specific message type 67 and 68 (sensor 2 frame navigation solution and rms).
- 08
  Horizontal speed and vertical velocity and quality (velocity flag) will be decoded from general GSOF message type 8 (Velocity).
  This message does not contain a (relative) track angle, only speed.

When continuing to the next wizard page just select [ Yes ] when this message-box pops up.

Third Wizard Page

On this last wizard setup page you can also change the default name of each observation (as long as it doesn't exceed 16 characters). You may leave all parameters at their defaults.
Speed units must be 'Meters / Second'
Angle unit must be 'Degrees'

Acceleration Velocity Sensor

Add an Acceleration Velocity Sensor to your template setup and select driver:

"Trimble/Applanix GSOF (Velo, Acc, RoT)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Velo, Acc, RoT)" when using the network interface.

Velocity, acceleration and rotation observations will be decoded from:

one of the AP+ specific message types (49, 63, 65, 67).

First Wizard Page

Example of UDP network interface

Second Wizard Page

Add the required observation types that you want and select for each one the location that represent the frame for the selected Slot 1.
You may change the default name for each observation as long as it doesn't exceed 16 characters.

Note that from the listed observation types the types Velocity (X/Y/Z) are not supported so adding these three has no use.

Important is to select for each observation the Slot 1 Id which defines from which GSOF message the observations will be decoded:
- REFERENCE
  Observations and qualities will be decoded from AP+ specific message type 49 and 50 (reference frame navigation solution and rms).
- VESSEL
  Observations and qualities will be decoded from AP+ specific message type 63 and 64 (vessel frame navigation solution and rms).
- SENSOR1
  Observations and qualities will be decoded from AP+ specific message type 65 and 66 (sensor 1 frame navigation solution and rms).
- SENSOR2
  Observations and qualities will be decoded from AP+ specific message type 67 and 68 (sensor 2 frame navigation solution and rms).

When continuing to the next wizard page please select [Yes] when this message-box pops up.

Third Wizard Page

On this last wizard setup page you can also change the default name of each observation (as long as it doesn't exceed 16 characters). You may leave all parameters at their defaults.
Speed units must be 'Meters / Second'
Acceleration units must be 'Meters / Second^{^2}'
Rate-of-Turn units must be 'Degrees / Second'

Notes

Adding velocity, acceleration and rotation observations can be useful for analyzing purposes e.g. by monitoring their values in real-time using an Observation Physics Display or graphically using a Timeplot Display.

However these type of observations will not be used by Qinsy to enhance the computation results.

If you need to enhance the result from a possible kalman filter in your computation setup then you should use the angle and speed observations from the Speed Log system setup.

Miscellaneous System

Add a Miscellaneous System to your template setup and select driver:

"Trimble/Applanix GSOF (Metadata)" when using the serial I/O interface, or
"Network (UDP/TCP) - Trimble/Applanix GSOF (Metadata)" when using the network interface.

Generic observations will be decoded from:

the header of any AP+ specific message type
and/or from standard GSOF message type 1 or 37.

First Wizard Page

Example of TCP network interface

Second Wizard Page

Here you can add up to nine generic observations that you may want to monitor.
Each generic observation needs a unique Slot Id so the driver knows which field to decode.
It is highly recommended to use the drop-down selection for the correct Slot Id:

More convenient may be to use the checkbox to add all observations at once.

Of course you can change the default name for each observation as long as it doesn't exceed 16 characters.

Find below a table with all possible Slot IDs:

Slot 1 ID	Observation	GSOF Message
BATTERY	Remaining battery capacity in percentage	37 (Battery/Memory info)
GNSS_QUAL	GNSS Quality Indicator: 0: Fix Not Available 1: GNSS SPS Mode 2: Differential GPS SPS 3: GNSS PPS Mode 4: Fixed RTK Mode 5: Float RTK 6: DR Mode	From any AP+ specific message header
HOURS_LEFT	Estimated remaining data logging time in hours	37 (Battery/Memory info)
INIT_COUNT	Initialization counter (Increments with each initialization, modulo 256)	1
INS_QUAL	INS Quality indicator: 0: GPS Only 1: Coarse leveling 2: Degraded 3: Aligned 4: Full Navigation	From any AP+ specific message header
NR_SV	Nr of satellites used to determine the position	1 (Position Time)
POS_FLAG1	Flag representing first set of position attribute values: Bit 0: New position (0: No, 1: Yes) Bit 1: Clock fix calculated for current position (0: No, 1: Yes) Bit 2: Horizontal coordinates calculated this position (0: No, 1: Yes) Bit 3: Height calculated this position (0: No, 1: Yes) Bit 4: Reserved (Always 1) Bit 5: Least squares position (0: No, 1: Yes) Bit 6: Reserved (Always 0) Bit 7: Position uses filtered L1 pseudo ranges (0: No, 1: Yes)	1 (Position Time)
POS_FLAG2	Flag representing second set of position attribute values: Bit 0: Differential position (0: Differential position is an autonomous or a WAAS solution, 1: Position is a differential solution) Bit 1: Differential position method (0: Code, 1: Phase including RTK, HP or XP OmniSTAR, VBS is not derived from Phase) Bit 2: Differential position method (0: Code (DGPS) or a float position (RTK). Uncorrected position is Autonomous if bit 0 = 0, 1: Position is fixed integer phase position (RTK). Uncorrected position is WAAS if bit 0 = 0) Bit 3: OmniSTAR solution (0: Not active, 1: OmniSTAR differential solution, including HP, XP, and VBS) Bit 4: Position determined with static as a constraint (0: No, 1: Yes) Bit 5: Position is network RTK solution (0: No, 1: Yes) Bit 6: Position is Location RTK (0: No, 1: Yes) Bit 7: Position is Beacon DGPS (0: No, 1: Yes)	1 (Position Time)
RCV_STATUS	Flag representing Receiver Status Code: Bit 0: Reserved Bit 1: Low battery at base station (1) Bit 2: Reserved Bit 3: Kinematic state is 'Roving' (1) or 'static' (0) Bit 4-7: Reserved	From any General Packet Header (GENOUT)

Note that the Slot ID is case-sensitive.

Third Wizard Page

Here you can also change the default name of each observation as long as it doesn't exceed 16 characters.
You may leave all parameters at their defaults.

Online

The driver has no user-interface so you need to set up several displays to see if data is received, decoded and what the computed results are.

Click here for some examples of useful displays to use with your project...

Alert Display

Always useful as a starter to see if data is coming in at the I/O port or not.

Observation Physics Display

An observation physics display is useful to see if data is coming in, at what update rate and how the values are decoded.

Timeplot Display

A timeplot display is useful to monitor the observations graphically in time with min/max/mean statistics.

Generic Display

A generic display is particular useful to show the meaning of the several status indicators from the meta data observations (GNSS Quality, INS Quality, Receiver Status, Nr of SV's)

You may use the attached GSOF.xml file as example for getting all the information from the meta data observations .

Copy the layout (Use right-mouse 'Save Link As...') to your current Project's Settings\Display folder and open it using a new Generic Display.
Please note that Save as will not work when you are viewing this document offline through the Qinsy Console; it is only accessible via the QPS website.

After downloading you only need to select the correct miscellaneous system and generic observation as defined in your template setup:

The background picture in this generic display example is not embedded but feel free to browse for your own one 😉

Time Synchronization Display

A time synchronization display is mandatory to verify the accurate timing of all observations using the current UTC time from the unit.

The display will be automatically present when you have added a Time Synchronization System (aka PPS) to your template setup

For this you should have enabled standard GSOF message type 16 (Current Time UTC) with an update rate set to 1 Hz, as explained in the System Interfacing paragraph:

The binary message type 16 contains the GPS week number, the GPS week seconds and a GPS to UTC offset value (aka leap-second).
The values will be decoded by the driver and for easy monitoring also formatted as a text string in the status column of the Time Synchronization display:

[#16 wk nnnn, sec ssssss.ss, leap nn sec, flags nn, hh:mm:ss.s UTC]

In the examples above you'll see for the flags value: '11': the first 1 means that the time is valid and therefore accepted by the driver and the second 1 means that the UTC offset value (leap 18) is valid and therefore also accepted by the driver in order to convert GPS time to UTC.