Network - OXTS Inertial+ (MCOM iHeave) - 23

Description

Driver to decode Position (Lat/Lon/Height), Heading and/or Motion (Pitch, Roll, Heave) from Coda Octopus F180, outputting binary MCOM message.

Driver can also log the incoming data to a binary or ASCII file for post-processing heave purposes (iHeave). For this you need to add a Miscellaneous system to your template setup.

Two versions of the driver are available: a Serial version and a Network version (UDP). We strongly recommend usage of the UDP version because of the high amount of data broadcast by the F180.
The F180 usually outputs on port 3000. Data can be received directly from the sensor or via the F180 software application.

Note that when iHeave is to be used to always let the data pass through the F180 software application since that is the place where the filtering is carried out.

Driver Information

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 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 (hard coded). So the final observation time will always end with .xx5, e.g. 10.005, 10.015, 10.025 etc.

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

Note

Qinsy currently applies 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 5msec 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 results.

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 upward !!!

  
  For all a-priori SD values, please consult the manufacturer.

Miscellaneous

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.

Add a miscellaneous system to your setup and select driver “Network - OXTS Inertial+ (MCOM iHeave)”. Use the same I/O parameters as for the others. On the 2nd wizard page there is no need to add an observation so you can skip the warning message and continue to finish this setup dialog.

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-Time Synchronization and the UTC option this latency is also applied.

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!

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-Time Synchronization interface driver, then time stamping of the data is done at time of receiving.

Registry settings

To decode the Sensor data regardless of the navigation status, it is possible to adjust this registry value of 00 into 01 under:

HKEY_CURRENT_USER\SOFTWARE\QPS\QINSy\8.0\Drivers\DrvQPSCountedUDP\Settings\ Allow All MCOM NavStatus

Additional Information

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