Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Deck of Cards
id0002
Card
labelInfo

Driver Information

DriverNetwork - Coda Octopus F180Interface TypeUDPDriver Class TypeCounted
UTC Driver (question)YesInput / OutputInputExecutableDrvQPSCountedUDP.exe F180 PPS
Related Systems
Content by Label
showLabelsfalse
spacesdm
showSpacefalse
sorttitle
excerpttrue
excerptTypesimple
cqllabel = "dm-0162" and space = "dm"
labelsdm-0162
Related Pages 
Table of Contents
Table of Contents
maxLevel3
stylesquare
typeflat
separatorpipe

Show If
groupqps-staff, confluence-driver_format_access
Card
labelFormat

Include Page
DM-0162 - Format
DM-0162 - Format

Card
labelDecoding Notes

Decoding Notes

The Sync byte may be at the start of the message or at the end of the message depending on the software version of the F180. The driver will automatically detect this.

The Timestamp timestamp of the F180 increments at 10 msec steps (.010, .020, .030 etc). If the msec part of the timestamp doesn't end with 0 (e.g. not .010 but .012) then the message is rejected. According to the manual there is a 5 milliseconds latency on the time stamp inside the message. The driver will correct for this and will subtract 5 milliseconds from the time (hardcoded). So the final observation time will always end with .xx5, e.g. 10.005, 10.015, 10.025 etc.

If any of the three checksums are invalid then the message is rejected. If the length is not equal to 84 bytes then it is also rejected.

Note

Qinsy is currently applying 5ms latency to the MCOM format

When using 1PPS and timestamp on both QINSy and the F-180 then there is a latency of about 4.7ms (or 5ms) compared to the time in the message
Timing on arrival when the first RS232 character arrives (or the Ethernet packet arrives) then the delay is 8.9ms The filtering delay is about 4.7ms (or call it phase delay). The 8.9ms includes the calculation and the filter delay.

Latencies, other than the 5ms applied by QINSy, can be corrected by using:

  1. QINSy (Raw Data manager)
    1. Analyse for applying latencies to (time shifting) the data
    2. Replay for computing new result using the db files that contain the new latencies.
  2. Qimera for applying latencies en recalculating the ne results.
Card
labelDbSetup

Database Setup

Position

  • 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.

Heading

  • 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:

    Roll

    Positive heeling to starboard

    Pitch

    Positive bow up

    Heave

    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:
-udp_mcom_20
-undulation_0.0
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 and the UTC option this latency is also applied.

Card
labelDrivers.io

Drivers IO Notes

Command line parameter description for "drivers.io" file. Please do not edit this drivers.io file, or only after contacting the QPS Support department.

Cmdline 'F180' tells the driver to expect data from an F180 unit.

Cmdline 'PPS' tells the driver to use the time fields of the data string to timestamp the data. It is highly recommended to use these time fields of the data, especially when using the Network driver. If this cmdline parameter is omitted, or your template has no setup for a PPS interface driver, then time stamping of the data is done at time of receiving.

Card
labelOnline

Online

The following setup is recommended to monitor the performance of the F180.

Pitch / Roll / Heave

  • The quality indicators of the pitch/roll should be zero. You only need to monitor one of them since they are  filed with the same value (Channel 16, byte 6). 

    Note

    If the Quality indicator is not equal to zero then pitch/roll/heading fields are NOT VALID.

    If the Pitch/Roll/Heave is not valid, QINSy will not apply the motion to the data!!!

Heading

  • The Quality indicator of the heading is the decoded MCOM navigation status (Byte 21 of Message). This can be considered to be an F180 overall system performance indicator.
    In short

    0

    all invalid

    1

    Raw IMU measurements

    2

    Initializing

    3

    Locking

    4

    Locked = Valid

    Only 4 is a workable real-time mode. So make sure to monitor the heading quality indicator at all times. If this indicator is not equal to 4 then seriously consider stopping the survey since F180 data is not guaranteed to be real-time!

Card
labelAdditional Info

Additional Information

References: Coda Octopus publication: PF180 MCOM Format Description Version xx.