My Tickets

Drivers Manual

Network - TSS R-P-H (320-335-DMS) - 03

Description

Driver to be used to decode roll-pitch-heave observations from TSS motion reference units.

Two versions of the driver are available: a Serial version and a Network version (UDP). The internal workings of the drivers are the same except for the data reception.

Note that this driver only decodes the so-called TSS1 or TSS3 telegram format, it does not decode the TSS2 telegram format.

Driver Information

Driver TSS R-P-H (320-335-DMS)  Interface Type UDP / Serial Driver Class Type Counted 
UTC Driver (question) No Input / Output Input Executable DrvTSSNewUDP.exe 
Related Systems
Related Pages  



Decoding Notes

Accelerations and remote heave data (fields 2 and 3 in both formats) are not decoded by the QINSy driver.

The status symbols of the TSS message are decoded according to the following table:

Status symbol

Description

QI number in QINSy

<space>

No quality info

0.0

?

Heave bad quality

-1.0 for heave, 0.0 for pitch & roll

u

Unaided mode: still settling

-1.1

g

GPS aided mode: still settling

-2.2

h

Heading aided mode: still settling

-3.3

f

Full aided mode: still settling

-4.4

U

Unaided mode

1.0

G

GPS aided mode

2.0

H

Heading aided mode

3.0

F

Full aided mode

4.0

If the QI number (quality indicator) is negative, the data is decoded correctly, but is not used in QINSy.

To prevent this, driver "03 - TSS DMS R-P-H (Ignore Status)" can be used. This driver turns all quality indicator values into positive numbers so that bad quality data is also used.

Interfacing Notes

QPS recommends to set the update rate of the MRU system to a maximum of 25 Hz for marine applications.

Setting the unit to Continuous Data Stream may cause problems in QINSy because of the possibility of a buffer overflow.

Drivers IO Notes

Command line parameter "320" or "DMS" indicate TSS unit types, but make no difference.

Command line parameter "OCTANS" indicates a reversed heave value input; the driver will correct for this (!).

Command line parameter "OI" indicates that the timetags are obtained from preceding "OiSTAR" headers, if available. Otherwise the first incoming byte is timetagged.

Command line parameter "NOCS" indicates that all decoded data will be accepted, even when the status indicator flag of the message states that the unit is still settling (i.e. lower case "u", "g", "h" and/or "f")