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).
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||Network - Coda Octopus F180||Interface Type||UDP||Driver Class Type||Counted|
|UTC Driver||Yes||Input / Output||Input||Executable||DrvQPSCountedUDP.exe F180 PPS|
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.
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:
- Qinsy (Raw Data manager)
- Analyse for applying latencies to (time shifting) the data
- Replay for computing new result using the db files that contain the new latencies.
- Qimera for applying latencies en recalculating the results.
- 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 upward !!!
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.
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).
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!!!
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.
Raw IMU measurements
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.
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
References: Coda Octopus publication: PF180 MCOM Format Description Version xx.