- In order to decode a position from the F180, add a Position Navigation System to your template and select the driver "Coda Octopus F180 Position (Network with UTC)". The port number must be the same as the output port number of the F180 unit or topside software. Normally this will be 3000. The receiver number can be set to any value.
Select for Horizontal and Vertical datum WGS84.
- In order to decode a heading from the F180, add a Gyro and Compass System to your template and select the driver "Coda Octopus F180 Heading (Network with UTC)". The port number must be the same as the output port number of the F180 unit or topside software. Normally this will be 3000. Slot number is not necessary.
Pitch / Roll / Heave
In order to decode the attitude from the F180, add a Pitch, Roll and Heave Sensor System to your template and select the driver "Coda Octopus F180 R-P-H (Network with UTC)". The port number must be the same as the output port number of the F180 unit or topside software. Normally this will be 3000. Slot number is not necessary.
Rotation Convention and Sign:
Positive heeling to starboard
Positive bow up
Positive downwards !!!
For all a-priori SD values, please consult the manufacturer.
Special Note: iHeave
The F180 topside application outputs long period filtered heave, also referred to as iHeave, and its latency. Note that the F180 unit itself does NOT calculate the filtered heave so only data that came through the F180 topside application can contain valid iHeave data. The filtered heave is considered to be superior to the real time heave since it can also follow very slow height changes that would otherwise fall outside the bandwidth of the real time heave filter. Downside of course is that the filtered heave is lagging minutes behind on the real-time heave so it is unsuitable for real-time purposes. So for the purpose of post-processing the driver can log the incoming MCOM packets into a file. It can also log the filtered heave data into an ASCII file. The logging functionality can be enabled by changing a registry key (see below). By default the logging functionality is DISABLED.
As soon as you go on-line, and valid post-processed heave data is decoded by the driver, a binary file will be created in your project's Import folder, containing all incoming MCOM messages. Filename convention was "F180 TRUE HEAVE (dd-MMM-yyyy).bin", but as of QINSy v8.1 it is "F180 iHEAVE - <System Name> (dd-MMM-yyyy).bin".
At the same time an ASCII file is created in the same folder with the same filename, but with extension *.txt. This file contains a readable representation of the MCOM Heave data. The format is compatible with the ASCII file format for the POS M/V version 4 driver: comma-separated fields showing UTC date and time of the filtered heave, and the rest zeros.
This text file can not be used in the Validator with the "Shift [Z] by File"-Filter, since the MCOM format doesn't contain the real time heave valid for the filtered heave timestamp.
The logging can be enabled with a registry editor (e.g. regedit.exe). Look up the following registry key, in order to change the behavior: "HKEY_CURRENT_USER\Software\QPS\QINSy\8.0\Drivers\F180 True Heave Logger\Settings"
Append is default set to 1. If you change it to 0, any existing file will be overwritten.
Ascii is default set to 1. If you change it to 0, no ASCII file will be stored.
Binary is default set to 1. If you change it to 0, no binary MCOM records will be stored.
LogAlways is default set to 0. If you change it to 1, data will be stored to disk.
Processing: The ASCII or binary files can be imported back into the recorded databases with the Import ASCII tool. After importing a replay of the databases is required.
Special Note: OXTS Inertial+
For the Inertial+ the MCOM output needs to be enabled and the undulation needs to be set.
The frequency of the MCOM can also be set, in the below example it is set to 20 Hz.
In i+config go to the options page, advanced option, paste in the following lines:
Note on Latency: For the network drivers it is not possible to set the latency field, therefore the latency of 5 milliseconds is applied hard-coded inside the driver. When the Serial driver is used in combination with PPS-Time Synchronization and the UTC option this latency is also applied.