USBL SeaTrac Developer Guide
USBL SeaTrac Developer Guide
USBL SeaTrac Developer Guide
Acoustic Beacons
Serial Command Interface
Reference
(for firmware version 1.2)
UM-140-D00221-02
SeaTrac Serial Command Interface Reference
Contents
1. Document Revision and Change History ........................................................................ 6
2. Introduction .............................................................................................................. 9
2.1. Overview and Scope ............................................................................................. 9
2.2. Numerical Notations ........................................................................................... 10
2.3. Diagnostic Tools ................................................................................................ 10
2.4. Technical Support .............................................................................................. 10
2.5. Notices ............................................................................................................. 11
Page 2
SeaTrac Serial Command Interface Reference
Page 3
SeaTrac Serial Command Interface Reference
Page 4
SeaTrac Serial Command Interface Reference
Page 5
SeaTrac Serial Command Interface Reference
Developers upgrading beacon firmware should use the following summary list to check
for compatibility in command message encoding and decoding algorithms.
SETTINGS_T structure modified to contain new Position Filter enable flag and control
fields – XCVR_POSFLT_ENABLE, XCVR_POSFLT_VEL, XCVR_POSFLT_ANG and
XCVR_POSFLT_TMO. Fields are appended on the end of the structure for backward
compatibility.
Page 6
SeaTrac Serial Command Interface Reference
o Six new CST_XCVR_STATE… codes have been added for use with the
CID_XCVR_STATUS command.
o DAT_MODE_E enumeration removed as not required.
o The 32-bit FLAGS field in the HARDWARE_T structure has been spit into two 16-
bit fields, representing system (factory set) flags, and user flags.
o CID_XCVR_RX_RESP_ERROR removed and functionality merged with
CID_XCVR_RX_ERR message.
o CID_XCVR_RX_ERR message contains the new ACOFIX_T structure describing
the received acoustic signal.
o CID_XCVR_RX_MSG, CID_XCVR_RX_REQ and CID_XCVR_RX_RESP include
ACOFIX_T structure describing the received acoustic signal.
o CID_XCVR_FIX command now uses the new ACOFIX_T structure.
o New CID_XCVR_STATUS command added to allow the current status of the
acoustic transceiver to be queried – responses include Idle, Transmitting,
Receiving Header, Receiving Data etc.
o CID_PING_SEND command now has a MSG_TYPE field to specify how messages
are sent – either as Request Standard (MSG_REQ), Request USBL (MSG_REQU)
or Request Enhanced USBL (MSG_REQX) types. This allows finer control over
acoustic transmission types and timings.
o CID_PING_REQ and CID_PING_RESP messages now contain the new ACOFIX_T
structure – this means the XCVR_FIX_MSGS flag is no longer required to be set
in the acoustic transceiver settings.
o CID_ECHO_SEND command now has a MSG_TYPE field to specify how messages
are sent – either as Request Standard (MSG_REQ), Request USBL (MSG_REQU)
or Request Enhanced USBL (MSG_REQX) types. This allows finer control over
acoustic transmission types and timings.
o CID_ECHO_REQ and CID_ECHO_RESP messages now contain the new ACOFIX_T
structure – this means the XCVR_FIX_MSGS flag is no longer required to be set
in the acoustic transceiver settings.
o CID_DAT_SEND command now has a MSG_TYPE field (replacing FLAGS field and
obsolete DAT_MODE_E enumeration) to specify how messages are sent.
o CID_DAT_SEND command DEST_ID parameter now allows a value of
BEACON_ALL (0) to send data to all beacons. However the MSG_TYPE type must
be either MSG_OWAY or MSG_OWAYU.
o New commands CID_DAT_QUEUE_SET, CID_DAT_QUEUE_CLR and
CID_DAT_QUEUE_STATUS added to allow data to be queued at a remote
beacon, and transmitted back in a response.
o Command format for CID_DAT_RECEIVE updated to use the new ACOFIX_T
structure (support beacon fix information, acknowledge flag and is generated
upon receipt of an acknowledge message).
o CID_DAT_ACK message removed, as CID_DAT_RECEIVE now includes this
functionality.
Page 7
SeaTrac Serial Command Interface Reference
Firmware bug fixed in response turnaround timing where a timing error caused a range
error of up to 1m to be reported.
Page 8
SeaTrac Serial Command Interface Reference
2. Introduction
This document is intended to provide developers with the necessary information to allow
interfacing of SeaTrac Beacons with their systems using the serial communications port hardware
and command protocol, and intended to be read in addition to the hardware and operational
notes discussed in the specific Beacon’s user manual.
The subsequent sections of this document discuss the data types, constants and structures
commonly referenced by the serial command set, along with encoding schemes and a complete
reference for the serial messages accepted and generated by the beacon.
It is assumed that the reader has a reasonable level of programming expertise and is familiar
with the basic concepts of the serial port hardware within their chosen operating system, as well
as manipulation of numerical data types and basic software design principles.
Throughout this document the following symbols are used to indicate special precautions or
procedures you should note…
WARNING!
This symbol indicates a warning you should follow of to avoid bodily injury and damage
to your equipment.
CAUTION
This symbol denotes precautions and procedures you should follow to ensure correct
operation to your equipment, and in some situations (where noted) possible damage.
NOTE
This symbol denotes special instructions or tips that should help you get the best
performance from your beacons.
Page 9
SeaTrac Serial Command Interface Reference
The graphical interface provides user controls and displays to send messages to and from the
beacon hardware, and the communications “Journal” function keeps track of the individual serial
commands sent and received.
Clicking on each entry in the Journal will expand the message, showing the encoding/decoding
order of each message data field and its corresponding value(s) – this information can be used
in conjunction with the message reference descriptions provided in sections 7 and 8 to analyse
and debug the operation of the Beacon.
For further Technical Support on either software of hardware related issues please use the
contact details provided on the website above or in the Beacon’s user manual, and where possible
please have the products part number, serial number, firmware and software revision details
available.
We welcome any feedback you may have about SeaTrac products, from bug reports to ideas for
new features or hardware to support – please use the contact details on the website (or shown
below) to get in touch.
Page 10
SeaTrac Serial Command Interface Reference
2.5. Notices
Specifications and Content
The contents of this document are provided on an “as is” basis and although we try to ensure
the information presented here is correct at the time of going to press, this document may
contain some errors. Blueprint Design Engineering Ltd cannot be held responsible for any
inaccuracies or omissions. If you find an error or feel we have missed important or useful
information, please contact us. The latest version of this document is always available to
download from the website.
Specifications and information contained in this document are subject to change at any time
without notice, and does not represent a commitment on the part of Blueprint Design Engineering
Ltd.
Where possible, we will aim to re-release this document in conjunction with significant firmware
releases and updates, and will document the changes made to the documents technical contents
(commands, data structures, message formats etc) in the “Document Revision and Change
History” section (1) on page 6.
Acoustic Limitations
The operational ranges and performance that can be achieved between acoustic beacons
depends heavily on environmental factors (including water temperature, dissolved oxygen
content, marine plant life and man-made acoustic noise from passing vessels and submerged
equipment), geographical conditions (such as depth of channel, acoustic reverberation nearby
structures and obstacles that may block the acoustic transmission) and the mounting method,
orientation and position of the beacon of each operating platform.
Acoustic performance values stated in the documentation describe achievable results obtained
in favourable conditions.
Disclaimer
Neither Blueprint Design Engineering Ltd., or their affiliates shall be liable to the purchaser of
this product, or third parties, whether in tort, contract or otherwise for losses, costs, damages
or expenses incurred by the purchaser or third parties as a result of accident, misuse, abuse,
modification of this product or a failure to strictly comply with the operating and maintenance
instructions.
Trademarks
The Windows™ operating system is a trademark of the Microsoft Corporation. Other product and
brand names used within this document are for identification purposes only. Blueprint Design
Engineering Limited disclaims any and all rights in those marks.
Page 11
SeaTrac Serial Command Interface Reference
3. Beacon Architecture
The diagram below shows the hardware blocks in each beacon…
Config Switches
Power Supplies Supply Voltage EEPROM
Status LEDs
External Connector (5-way)
Main Tx/Rx
Transducer
USBL Receiver
(4 Channels)
AHRS Sensors
Pressure Sensor
(Acc, Mag, Gyro)
The X150 and X110 hardware are very similar, with the exception that X110 beacons do not
have the USBL receiver circuitry or transducers fitted.
The serial UART hardware features a 64-byte hardware receive buffer, from which data is
analysed and decoded started on reception of the correct “synchronisation character”. Decoding
and buffering of the command continues until the end of the message is reached at which time
it is executed by the relevant command handler function.
Further details of the serial command protocol are discussed in section 5 from page 9
onwards.
Serial commands are provided to allow the user to mage changes to the working RAM settings
or read them back, and to save of load the RAM settings back into EEPROM as required.
Page 12
SeaTrac Serial Command Interface Reference
However, like other memories of its type, the EEPROM memory has a lifetime endurance of
between 10,000 and 50,000 cycles, after which its data retention capabilities may start to
degrade (below the guaranteed 5 year period). For this reason, it is recommended that the
settings are only saved by to EEPROM following changes by the user, but not on an automated
periodic basis.
Some settings values can be automatically computed/changed as the beacon operates, such as
pressure-sensor offsets, velocity-of-sound and magnetic calibrations. When the beacon is
powered off, these changes will be lost unless specifically committed to EEPROM with a save
command. In practice though, on dynamic platforms it is often found that storing a default
calibration for the magnetometer is sufficient for start-up accuracy and the dynamic calibration
routine will further adjust the calibration as required by the magnetic environment. Values such
as pressure offset and VOS are computed within the first couple of seconds of operation.
Some settings, such as those controlling the communication hardware, are only applied on
power-up or a software reboot command. Details of these are discussed in section 6.4.9 on page
56.
Settings can be reset to factory values by either issuing a Reset serial command, or using the
magnetically triggered reset-to-default sequence – for further details refer to the Beacons user
manual.
Additionally, each beacon has a supply voltage monitoring circuit that can be used to provide
low-voltage alarms for battery powered systems. The data modem feature can be used to
optionally broadcast this information to other beacons on demand.
For further details on calibration procedures, refer to the Bacons user manual. Section 7.5 (from
page 87) deals with calibration configuration messages.
Page 13
SeaTrac Serial Command Interface Reference
Each beacon is configured by the user with a unique identification-code that allows up to 15
beacons to exchange acoustic data messages or broadcast to all other beacons in the network.
Messages are exchanged by a request/response process and when complete the sending beacon
is able to obtain timing information and a range measurement for the remotely interrogated
beacon.
When data is sent, the transceiver will use one of the message types are available…
Tracking and navigation systems can be built using one X150 is mounted from the supervisor
vessel, with an application controlling the sequential ‘pinging’ of remote beacons. All relative
Page 14
SeaTrac Serial Command Interface Reference
positions are computed internally and output the results via serial messages, so no additional
PC hardware is required.
In this mode up to 14 beacons may be tracked with the position of each being optionally
broadcast to others in the network, using the data modem feature.
Alternately, developers may use several X150 beacons fitted to divers or other subsea assets
and establish their own control algorithms to allow create a multiple access network where each
asset can “ping” and obtain positions for every other beacon.
For further details on Acoustic Protocols and their command sets, please refer to
section 8 from page 104.
PING Simple Ping protocol providing the basic ability to query if a beacon is
powered-up and on its response obtain a range and position for it.
Page 15
SeaTrac Serial Command Interface Reference
4. Getting Started
When using SeaTrac Beacons for the first time, ensure that you have read the Beacon’s User
Manual first and observed all the operating requirements and precautions.
Specially, the user manual covers the connector pin-outs used for making connections to the
beacon and the requirements of the power supply.
A PC with at least one RS-232 serial port, although dual serial ports are better for testing
both ends of an acoustic link with two beacons (a variety of RS232-to-USB serial
converters have been tested at 115200 baud and proved to also work well).
If the PC has Microsoft Windows installed, having a copy of SeaTrac Tools installed is
also recommended to help validate Beacon hardware is functioning correctly and
application development progresses.
A terminal application running on the PC to validate basic operation and view output
from the beacons serial port.
For each beacon in the setup, a separate bench-top power supply capable of delivering
at least 1 amp at 12V with a smoothed DC output.
Suitable leads to connect the beacon (or beacons) to the power supplies and RS232
serial ports.
The presence of the liquid around the transducer helps mechanically dampen it to its designed
operating levels and will reduce peak-current observed to be drawn from power supplies during
transmission.
Alternately, two separate small containers of water may be used to hold each beacon, and
operation should still be observed as the sound leaves one container, travels through air, and
enters the second.
Page 16
SeaTrac Serial Command Interface Reference
Taking the above note into account, development and testing of the beacons in air is still possible
so long as the developer is aware of the risks.
Beacons can be placed on a bench about 30cm to 50cm apart and should communicate
acoustically with each other, although sometimes it’s more reliable to use clamp-stands to hold
them away from the surface of the desk.
Developers should also be aware that in close proximity in air, there can be electro-magnetic
cross-talk and triggering between beacons (and their cabling) rather than successful receipt of
acoustic messages.
First, connect a beacon to the computers serial port and run a serial terminal application
to establish a connection (several free “serial terminal” applications are available to
download from the internet).
If required set the terminal application to echo characters typed locally and append line-
feeds to carriage-return characters (so a <CR><LF> character pair is sent at the end
of messages).
When the beacon is powered up, a series of information messages should be displayed
in the terminal window along the lines of…
SEATRAC X-SERIES BEACON
Copyright (c) 2014 Blueprint Design Engineering Ltd. All rights reserved.
For further information, visit http://www.blueprintsubsea.com
Firmware Part BP00913, Version 1.0, Build 1915
Device Information...
Hardware Part Number = BP00795
Hardware Part Revision = 1
Hardware Serial Number = XXXXXX
Hardware Flags = 0x00000000
Hardware EUI48 = XX:XX:XX:XX:XX:XX
Bootloader Valid = 1
Bootloader Part Number = BP00912
Bootloader Version = v1.0.361
Page 17
SeaTrac Serial Command Interface Reference
Ready...
At this point the beacon is ready to receive serial commands. Type “#0281C1” and press
return – this will send a CID_SYS_INFO command requesting hardware and firmware
information.
Something similar to the following information string should be returned (if not a
formatting error message/code will be returned – see CST_E for appropriate return
codes)…
$0234000000011B0301690E000000000000FF900301006901B7FAC5BFFF910301007A077504
63A973BA
The fields in the above message can then be decoded using the information given in the
CID_SYS_INFO command reference section of this document. Alternately, you could use
the SeaTrac Tools application to send the above command, and use the “Journal” to
decode the information fields as…
Received Len = 41 bytes (in 83 chars)
Received Data =
"$0234000000011B0301690E000000000000FF900301006901B7FAC5BFFF910301007A07750
463A973BA"
CmdId = SYS_INFO (0x02)
Uptime = 0x00000034 (52)
Section = 0x01 (1)
HardwarePartNumber = 0x031B (795)
HardwarePartRevision = 0x01 (1)
HardwareSerialNumber = 0x00000E69 (3689)
HardwareFlags = 0x00000000 (0)
BootValid = TRUE
BootPartNumber = 0x0390 (912)
BootVersionMajor = 0x01 (1)
BootVersionMinor = 0x00 (0)
BootVersionBuild = 0x0169 (361)
BootChecksum = 0xBFC5FAB7 (3217423031)
AppValid = TRUE
AppPartNumber = 0x0391 (913)
AppVersionMajor = 0x01 (1)
AppVersionMinor = 0x00 (0)
AppVersionBuild = 0x077A (1914)
AppChecksum = 0xA9630475 (2841838709)
Page 18
SeaTrac Serial Command Interface Reference
First define the SETTINGS_T structure in your application – you will require this to read
settings into.
Send a CID_SETTINGS_GET command to the beacon, and parse the response into a
field of type SETTINGS_T – this will include the current sensor calibration values in use.
Modify the settings structure as required then write values back into the Beacons RAM
using the CID_SETTINGS_SET command. Most settings will be applied immediately, but
some (such as communication settings) will only be applied following a power-up or
software reboot command.
It may be required to store these new settings back into EEPROM, in which case now
issue the CID_SETTINGS_SAVE command. Note that if automatic calculation of VOS and
pressure offset are enabled, the previously specified values will be overwritten with the
computed values.
In the terminal application, typing “#10000DC0” will prompt for a CID_STATUS message
using the output flags configured in the settings.
Assuming the default flags of “Environment”, “AHRS” and “Magnetic Calibration” are
specified, something similar to the following message will be received…
$10078D48100000000000B930C2000800000000000000480DE3FD0DFD320303FF2B0400005E
F273
Page 19
SeaTrac Serial Command Interface Reference
AttitudePitch = -755
AttitudeRoll = 818
MagCalBuf = 0x03 (3)
MagCalValid = TRUE
MagCalAge = 0x0000042B (1067)
MagCalFit = 0x5E (94)
Alternately, you can specify a CID_STATUS with the first parameter as a combination of
flags defined by the STATUS_BITS_T type – this allows the content of the message to
be specified on a case-by-case basis.
Automatic generation of Status Messages can be specified (or disabled) by choosing the
appropriate value from the STATUSMODE_E enumeration and send this via either the
CID_SETTINGS_SET or CID_STATUS_CFG_SET commands.
Accelerometer Calibration
Prompt the user to hold the beacon steady and in an upright position and indicate when
they are ready to commence.
To give user feedback, turn on the outputting of accelerometer sensor and calibration
status information using either the CID_SETTINGS_SET or CID_STATUS_CFG_SET
command. It is recommend that the output rate be chosen to be either 5Hz or 10Hz
with the STATUSMODE_E enumeration, and the STATUS_BITS_T type for
STATUS_OUTPUT contain the ACC_CAL and AHRS_RAW_DATA bits.
Prompt the user to then hold the beacon horizontally and slowly rotate it clockwise and
anti-clockwise to find the minimum and maximum values for the X and Y axis.
The user should indicate when all 6 values have been successfully found, and the
CID_CAL_ACTION command with the ACTION parameter chosen to be CAL_ACC_CALC
(from the CAL_ACTION_E enumeration) to compute the Pitch and Roll limits.
Page 20
SeaTrac Serial Command Interface Reference
Optionally at this point the Accelerometer Calibration could be stored to EEPROM using
the CID_SETTINGS_SAVE command.
Magnetometer Calibration
To give user feedback, turn on the outputting of magnetometer sensor and calibration
status information using either the CID_SETTINGS_SET or CID_STATUS_CFG_SET
command. It is recommend that the output rate be chosen to be either 5Hz or 10Hz
with the STATUSMODE_E enumeration, and the STATUS_BITS_T type for
STATUS_OUTPUT contain the MAG_CAL and AHRS_RAW_DATA bits.
Prompt the user to start rotating the beacon around all 3-axis in 3D space. As the beacon
is rotated the Pitch and Roll information is used to build up a 3D magnetic map
surrounding the beacon in the calibration buffer.
Displaying the MAG_CAL_BUF value output in CID_STATUS message can give the user
feedback on the calibration process. When the value reaches 100, calibration is complete
and the user can be prompted to stop movement.
Optionally at this point the Magnetometer Calibration could be stored to EEPROM using
the CID_SETTINGS_SAVE command.
This section covers the use of basic interrogation and operating a simple network that tracks the
position of several beacons using the PING protocol. Information on other protocols can be found
in section 8 from page 104 onwards.
Using a process similar to that described in section 4.3 above, a single beacon can be Pinged
using the following commands…
Page 21
SeaTrac Serial Command Interface Reference
Start as described previously in section 4.4 by retrieving the beacon settings into a
SETTINGS_T structure.
Check that each remote beacon is assigned a unique beacon ID for the network
addressing in the XCVR_BEACON_ID field.
Check each remote beacon uses the same response turnaround time value in the
XCVR_RESP_TIME field – typically this should be 10ms.
Program any settings changed back into the beacon using the CID_SETTINGS_SET and
CID_SETTINGS_SAVE commands.
Start as described previously in section 4.4 by retrieving the beacon settings into a
SETTINGS_T structure.
Request that position fix messages are generated by the acoustic transponder by
settings the XCVR_FIX_MSGS flag in the XCVR_FLAGS field. Additionally specifying the
XCVR_DIAG_MSGS flag will also request that further transceiver activity and status
information is output.
Setup the range (and hence amount of time) the transponder will wait for a remote
beacon to respond to a request before a timeout error is raised by specifying the value
of the XCVR_RANGE_TMO value.
Check that the beacon is assigned a unique beacon ID for the network addressing in the
XCVR_BEACON_ID field.
Check the beacon uses the same response turnaround time value as the remote
beacons, in the XCVR_RESP_TIME field – typically this should be 10ms.
Program any settings changed back into the beacon using the CID_SETTINGS_SET and
CID_SETTINGS_SAVE commands.
Interrogating Beacons
When the acoustic transponder is idle, send the CID_PING_SEND command along with
a remote Beacon ID code to start a ping sequence. The beacon will immediately output
a status response message indicating if the transponder is busy or if transmission has
started. The acoustic transceiver will transmit a PING Request message
On reception of the PING Request, the remote beacon will output as CID_PING_REQ
serial message locally – this is for information only, so it does not matter if the remote
beacon has a serial link connected.
At some point later in time (proportional to the range of the remote beacon) as PING
Response acoustic message should be received and the local beacon will signal success
with a CID_PING_RESP message.
Page 22
SeaTrac Serial Command Interface Reference
Because of the previous configuration, the local beacon will generate a CID_XCVR_FIX
message that contains ranging information. Additionally, if the local beacon is an X150
model this message will also contain positioning information.
If no response is received by the local beacon, after the previously configured Range
Timeout period has been observed a CID_PING_ERROR message will be generated
indicating the beacon has timed out.
Controlling Algorithm
By using the above procedure, developers can build their own control algorithms that poll a
network of remote beacons, obtaining positing information for each one.
Iterations of the main loop should poll each beacon in turn (with a CID_PING_SEND command)
and either wait for a CID_PING_RESP message (and CID_XCVR_FIX) to indicate success and
position, or a CID_PING_ERROR message to indicate a timeout and the remote beacon cannot
be communicated with (or is not present).
This information can be presented to the user in the most suitable way for the developers
application.
Page 23
SeaTrac Serial Command Interface Reference
5. Serial Protocol
Communications between a SeaTrac Beacon and controlling device (such as a PC or embedded
system) take the form of Command Messages sent to the Beacon, and Response (or Status)
Messages received back from it.
All Command Messages issued to the Beacon are acknowledged by a Response Message, and
occasionally Status messages are generated by the beacon in response to system events (such
as message reception etc).
Command and Response messages share the same message structure, as shown in the diagrams
below…
Page 24
SeaTrac Serial Command Interface Reference
Messages from the PC to the Beacon should start with a ‘#’ character (ASCII code 35).
Messages from the Beacon to the PC start with a ‘$’ character (ASCII code 36).
For data values that require more than one byte in size to transmit (i.e. 16-bit Words and 32-
bit DWords), the value is transmitted least-significant-byte first (Little-Endian).
Data lengths should always be a multiple of 2 as single nibble (character) values are never used.
All acknowledgement Response Messages sent from the Beacon use the same CID as that
specified in the Command Message sent to the Beacon.
For a list of valid CID codes see section 6.3.6, and section 7 for definitions of their purpose.
5.6. Checksums
The last 4 characters of each message (prior to the <CR><LF> characters) represent the 16-bit
checksum value (send in Little-Endian form).
Page 25
SeaTrac Serial Command Interface Reference
Checksums are computed by processing in a sequential byte-wise fashion the messages binary
content after (but not including) the synchronisation character, and not including the checksum
value itself – i.e. the CID and Payload message fields.
This means that the ASCII-Hex characters of the message string should first be decoded into an
array of bytes representing their values, as described in section 5.4 (such that “32A9C4” would
become 0x32, 0xA9, 0xC4), and then the array values used to compute the checksum.
This applies both to received and transmitted messages.
Message checksums are generated using the CRC-16-IBM polynomial of x16 x15 x 2 1 .
(Normal polynomial 0x8005, Reversed polynomial of 0xA001)
When receiving a message, the computed checksum should be compared against the received
checksum, and if the two values match then the message is considered valid.
When transmitting a message, a buffer should be populated with the CID and message payload,
then the checksum of this computed and appended to the end of the buffer.
The following C code shows a simple algorithm for computing the CRC of the message buffer…
/*!
Function that computes the CRC16 value for an array of sequential bytes
stored in memory.
NB: Types uint8 and uint16 represent unsigned 8 and 16 bit integers
Respectively.
@param buf Pointer to the start of the buffer to compute the CRC16 for.
@param len The number of bytes in the buffer to compute the CRC16 for.
@result The new CRC16 value.
*/
uint16 CalcCRC16(uint8* buf, uint16 len)
{
uint16 poly = 0xA001;
uint16 crc = 0;
Page 26
SeaTrac Serial Command Interface Reference
The following message strings show typical synchronisation, CID and checksum data, and can
be used to validate checksum algorithm implementations…
Page 27
SeaTrac Serial Command Interface Reference
1
For further details, see http://en.wikipedia.org/wiki/Double-precision_floating-point_format.
2
For further details, see http://en.wikipedia.org/wiki/Single_precision.
Page 28
SeaTrac Serial Command Interface Reference
6.2. Arrays
Arrays define sequential and continuous (packed) allocations of memory for a specific data type.
In the scope of this documentation, arrays are defined by the use of square brackets (“[ x ]”)
after a data type, with the value enclosed within the brackets denoting the number of storage
elements required. Examples are…
Unless otherwise stated, arrays element indices are specified from 0 up to the number of array
elements minus 1 – i.e. for a definition of x = UINT8[12], elements are defined as x[0] to x[11].
If a value is stored that is not a defined enumerator, then the value should be considered invalid
and unexpected application behaviour may occur as a result.
Depending on programming style, enumerations may also be defined as a storage value, such
as a UINT8 and value enumerators defined as constants that can then be assigned to this value.
Unless stated otherwise, all enumerations defined below are stored and transmitted as
UINT8 values.
Page 29
SeaTrac Serial Command Interface Reference
Page 30
SeaTrac Serial Command Interface Reference
Page 31
SeaTrac Serial Command Interface Reference
Page 32
SeaTrac Serial Command Interface Reference
0x0 BEACON_ALL (for transmit) When used as an address for sending acoustic
RESERVED (for receive) messages to, the value of 0x00 indicates
“broadcast to all”.
When used as an identifier of a sender of a
message, the value of 0x00 should be
interpreted as unknown or invalid.
Page 33
SeaTrac Serial Command Interface Reference
Page 34
SeaTrac Serial Command Interface Reference
The usage of each CID, including definition of message fields for both Command and Response
payloads is discussed in section 7 from page 64.
System Messages
Status Messages
Page 35
SeaTrac Serial Command Interface Reference
Settings Messages
Calibration Messages
Page 36
SeaTrac Serial Command Interface Reference
Page 37
SeaTrac Serial Command Interface Reference
Page 38
SeaTrac Serial Command Interface Reference
Page 39
SeaTrac Serial Command Interface Reference
Different Response messages may only implement a subset of the constants below, as
appropriate for their function. Further details about the status codes each CID response provides
are discussed in section 7 from page 64.
Page 40
SeaTrac Serial Command Interface Reference
Page 41
SeaTrac Serial Command Interface Reference
Page 42
SeaTrac Serial Command Interface Reference
Page 43
SeaTrac Serial Command Interface Reference
6.4. Structures
Structures (sometimes called Records or Structs) are declarations defining complex data types
of physically grouped variables placed under one name in a block of memory.
For the scope of this document, the members (or fields) of Structures should be assumed to be
defined sequentially in memory, with no additional packing bytes added.
MSG_DEST_ID BID_E Identifier for the beacon the message is or was the
recipient of the message.
MSG_SRC_ID BID_E Identifier for the beacon that generated or sent the
message.
MSG_TYPE AMSGTYPE_E Value that indicates the type of message being sent
Page 44
SeaTrac Serial Command Interface Reference
The data record varies depending on the contents of the FLAGS field, with required fields being
appended to the end of the record as required.
DEST_ID BID_E The ID code of the beacon that this data is sent to.
Normally this is the local beacon ID code, but a
value of BEACON_ALL indicates data has been
transmitted to all beacons.
Valid values are form 0 to 15.
SRC_ID BID_E The ID code of the beacon that sent the data.
Valid values are form 1 to 15.
Bit[4] = POSITION_FLT_ERROR If this bit is true, it indicates the position filter has
identified that the position specified in the fix may
be invalid based on the beacons previous position,
the define beacons motion limits and the time since
last communication. However, the position fields
still contain the USBL computed position and it is up
to the user if they wish to reject this fix, or use it in
some direct or weighted fashion.
Bit[3] = POSITION_ENHANCED If this bit is set, it indicates the Position fix has
been computed from an Enhanced USBL return –
this means the Depth will be the value from the
remote beacons depth sensor rather than computed
form the incoming signal angle.
Bit[2] = POSITION_VALID If this bit is set, it indicates the record contains the
Position fields discussed below.
Bit[1] = USBL_VALID If this bit is set, it indicates the record contains the
USBL fields discussed below.
Bit[0] = RANGE_VALID If this bit is set, it indicates the record contains the
Range fields discussed below.
Page 45
SeaTrac Serial Command Interface Reference
ATTITUDE_PITCH INT16 The pitch angle of the local beacon when the fix
was computed.
Values are encoded as deci-Degrees, so divide by
10 for just degrees to a 0.1° resolution.
ATTITUDE_ROLL INT16 The roll angle of the local beacon when the fix was
computed.
Values are encoded as deci-Degrees, so divide by
10 for just degrees to a 0.1° resolution.
DEPTH_LOCAL UINT16 The reading from the local beacon depth sensor
when the fix was calculated.
Values are encoded in decimetres, so divide by 10
to obtain a value in metres to a 0.1m resolution.
Range Fields
If the message FLAGS parameter contains the RANGE_VALID bit, then the following fields are
sequentially appended to the record…
Page 46
SeaTrac Serial Command Interface Reference
USBL Fields
If the message FLAGS parameter contains the USBL_VALID bit, then the following fields are
sequentially appended to the record…
USBL_FIT_ERROR INT16 The fit error value returns a number that indicates
the quality of fit (or confidence) of the signal
azimuth and elevation values from the timing and
phase-angle data available.
Position Fields
If the message FLAGS parameter contains the POSITION_VALID bit, then the following fields are
sequentially appended to the record…
Page 47
SeaTrac Serial Command Interface Reference
Page 48
SeaTrac Serial Command Interface Reference
Page 49
SeaTrac Serial Command Interface Reference
MAG_FIELD FLOAT The normalised (not actual) magnetic field used for
magnetometer calibration.
Valid values lie between 0 and 100, with a typical
value for idea fit being 50.
Default value is 0.
Page 50
SeaTrac Serial Command Interface Reference
VALID BOOLEAN Flag when true indicating the firmware is valid and
allowed to execute.
Page 51
SeaTrac Serial Command Interface Reference
Page 52
SeaTrac Serial Command Interface Reference
Or (Union)…
Page 53
SeaTrac Serial Command Interface Reference
Or (Union)…
Page 54
SeaTrac Serial Command Interface Reference
Page 55
SeaTrac Serial Command Interface Reference
As this structure contains current calibration and communication settings for the beacon, it is
always recommended to read the contents of the structure from the beacon rather than
populating a new structure from scratch.
See Settings manipulation commands in section 7.4 from 82 for further details.
Settings marked with the “” symbol are only applied on power-up or following a
CID_SYS_REBOOT command.
Page 56
SeaTrac Serial Command Interface Reference
Page 57
SeaTrac Serial Command Interface Reference
AHRS_FLAGS UINT8 This value contains flags that control the operation
of the beacons AHRS system.
Page 58
SeaTrac Serial Command Interface Reference
Page 59
SeaTrac Serial Command Interface Reference
Bit[1] = XCVR_POSFLT_ENABLE When this flag is true, the position filter is enabled
to mark potentially erroneous acoustic USBL fixes
based on velocity and angular movement limits.
Bit[0] = USBL_USE_AHRS When this flag is true the acoustic transceiver will
use the current AHRS attitude (updated internally
at a 50Hz rate) when resolving relative positions of
remote beacons to the local beacon.
XCVR_BEACON_ID BID_E The identification code the local beacon will accept
messages addressed to, or use as the source
identifier when sending messages.
Page 60
SeaTrac Serial Command Interface Reference
XCVR_YAW UINT16 When the AHRS attitude is not used to specify the
transceiver attitude, this value is used as the
manually specified yaw attitude from which relative
positions of remote beacons to the local beacon are
computed.
Attitudes are applied in the position calculation
routine via a Direction-Cosine-Matrix, in the Euler
sequence Yaw, Pitch then Roll.
XCVR_PITCH UINT16 When the AHRS attitude is not used to specify the
transceiver attitude, this value is used as the
manually specified pitch attitude from which
relative positions of remote beacons to the local
beacon are computed.
Attitudes are applied in the position calculation
routine via a Direction-Cosine-Matrix, in the Euler
sequence Yaw, Pitch then Roll.
Page 61
SeaTrac Serial Command Interface Reference
XCVR_ROLL UINT16 When the AHRS attitude is not used to specify the
transceiver attitude, this value is used as the
manually specified roll attitude from which relative
positions of remote beacons to the local beacon are
computed.
Attitudes are applied in the position calculation
routine via a Direction-Cosine-Matrix, in the Euler
sequence Yaw, Pitch then Roll.
XCVR_POSFLT_VEL UINT8 The maximum velocity limit (in metres per second)
that the position filter expects to see a beacon
move at. Position Fix outputs for Beacons that have
moved faster than this in the time between pings
will be marked as a position error.
XCVR_POSFLT_ANG UINT8 For beacons that are further away, azimuth errors
start to come into play. This value defines the
angular limits that beacons can move (or position
jitter) within without being marked as an error.
Vales are specified in degrees, and typically this
value is 10 degrees.
Page 62
SeaTrac Serial Command Interface Reference
Bit[4] = AHRS_RAW_DATA When set, appends raw sensor data fields to the
end of the status output message.
Bit[1] = ATTITUDE When set, appends the AHRS attitude (yaw, pitch,
roll) fields to the end of the status output message.
Page 63
SeaTrac Serial Command Interface Reference
7.1.1. CID_SYS_ALIVE
The CID_SYS_ALIVE command is a simple command that can be periodically sent to the beacon
to determine if the hardware is present, connected and functioning.
For example, a host system sending the CID_SYS_ALIVE command at regular intervals can use
the response reply to reset a “connection lost” timeout timer, so that when a connection fails
the lack of responses can indicate to the user the hardware is no longer present.
Page 64
SeaTrac Serial Command Interface Reference
7.1.2. CID_SYS_INFO
The CID_SYS_INFO command is used to receive hardware and firmware identification
information from the beacon. This information can then be used by external applications to
determine if firmware needs updating, or to determine support for Command Messages based
on the hardware type.
Page 65
SeaTrac Serial Command Interface Reference
7.1.3. CID_SYS_REBOOT
The CID_SYS_REBOOT command is sent to perform a software reset of the beacon. To prevent
accidental resets, the command requires an additional UINT16 constant value to be specified
after the CID code.
On receiving a valid reset command, the beacon performs the following actions…
The beacon restarts, any communications settings changes made will be applied.
Human readable power-up diagnostic information is output from the serial port.
Page 66
SeaTrac Serial Command Interface Reference
7.1.4. CID_SYS_ENGINEERING
The CID_SYS_ENGINEERING command is used for factory commissioning, diagnostic and
debugging purposes that lie outside the scope of this document.
Page 67
SeaTrac Serial Command Interface Reference
Opening the FWX firmware file in a text editor will show and XML structure and content similar
to below…
The file should be processed using an XML parser which will yield the following nodes…
FIMWARE This is the top level document node containing the CONFIG and
TARGET node.
Page 68
SeaTrac Serial Command Interface Reference
CONFIG This node contains overall configuration information for the firmware
file. At present the only TIMESTAMP sub node contains the build time-
stamp of the firmware.
TARGET The TARGET node contains firmware for each device. The attributes of
the target node define the overall properties of the firmware used by
the programming utility, and several of these are required to be sent
when starting programming using the CID_PROG_INIT command.
DATA The DATA nodes for the firmware target contains pre-formatted ASCII-
HEX data strings that should be sent to the device being programmed
using CID_PROG_BLOCK commands.
7.2.1. CID_PROG_INIT
The CID_PROG_INIT command is used to initialise the firmware programming sequence. Calling
this command will instruct the beacon to shut down the AHRS and Acoustic Transceiver systems
until programming is complete.
That command is sent along with several parameters that are obtained by parsing TARGET XML
node from the firmware FWX file provided by Blueprint. The beacon will examine these
parameters and determine if the firmware file is applicable to it and if it is ready to accept the
update.
Page 69
SeaTrac Serial Command Interface Reference
Page 70
SeaTrac Serial Command Interface Reference
7.2.2. CID_PROG_BLOCK
Once the CID_PROG_INIT command has been sent and accepted successfully by the beacon
(returning a STATUS code of CST_OK), the CID_PROG_BLOCK command is then sent repeatedly
to transfer each DATA node found in the FWX file under the required TARGET node.
Data in the FWX file is encoded in ASCII-HEX pairs, so for a DATA node length attribute of 64,
there will 128 ASCII-HEX characters.
A CID_PROG_BLOCK command should be sent for each DATA node in sequence, and a valid
STATUS code should be received back from the beacon before sending the next block.
DATA UINT8[x] An array of data bytes read from the relevant DATA
node in the FWX file, where “x” is the number of
bytes specified by DATA_LENGTH.
Page 71
SeaTrac Serial Command Interface Reference
Page 72
SeaTrac Serial Command Interface Reference
7.2.3. CID_PROG_UPDATE
Once all the CID_PROG_BLOCK commands have been sent in the correct sequence, the
CID_PROG_UPDATE command is used to transfer the new firmware from the working download
area into active memory.
This command may take up to 5 seconds to execute depending on the size of the firmware being
programmed.
If the command executes successfully, the status LED will illuminate yellow during the update
process, then the beacon will reboot.
Page 73
SeaTrac Serial Command Interface Reference
Status Messages can be either manually requested by issuing the CID_STATUS command, or set
to be automatically generated at specified time intervals (or disabled) by settings configured
with the CID_SETTINGS_SET or CID_STATUS_CFG_SET commands.
The allow optimisation of communication link bandwidth or reduce data overhead for logging
purposes, the information content of status messages it split into distinct groups (see
STATUS_BITS_T) and can be specified either in the system settings or at the time a manual
status request is made.
7.3.1. CID_STATUS
The CID_STATUS message serves several purposes: when issued as a command, it requests the
current beacon status at that point in time, or alternately it can be set to be output periodically
at specified intervals (through the STATUS_OUTPUT field of either the CID_SETTINGS_SET or
CID_STATUS_CFG_SET commands).
When issued as a manual status request command, an optional STATUS_OUTPUT value can be
specified in the CID_STATUS message to determine the information content of the response
message.
Omitting the STATUS_OUTPUT field causes the beacon to use the currently configured settings
option specified with the CID_SETTINGS_SET or CID_STATUS_CFG_SET commands. Alternately,
if the STATUS_OUTPUT value is specified, this will not update the stored settings value or alter
if status messages are also periodically generated.
This message is a status message that may be sent by the beacon at periodic time
intervals (not in response to a command message) depending on STATUS_OUTPUT
settings field – see SETTINGS_T and the CID_SETTINGS_SET or
CID_STATUS_CFG_SET commands.
Page 74
SeaTrac Serial Command Interface Reference
TIMESTAMP UINT64 The value of the beacon’s clock (set to zero when
the beacon was powered up – not rebooted!).
Values are encoded in milliseconds, so divide by
1000 for seconds.
Environmental Fields
If the message STATUS_OUTPUT parameter contains the ENVIRONMENT bit (see
STATUS_BITS_T), then the following fields are sequentially appended to the message record…
Page 75
SeaTrac Serial Command Interface Reference
Attitude Fields
If the message STATUS_OUTPUT parameter contains the ATTITUDE bit (see STATUS_BITS_T),
then the following fields are sequentially appended to the message record.
For details of attitude definitions refer to section 9.1 on page 135.
MAG_CAL_BUF UINT8 Value that indicates how full the data buffer is that
holds magnetometer values describing the
surrounding magnetic environment.
Values are encoded as a percentage from 0 to 100
representing empty (where no magnetic calibration
is possible) to full (where the best magnetic
calibration can be computed).
MAG_CAL_AGE UINT32 The number of seconds that have elapsed since the
magnetometer calibration was last computed.
When dynamic calibration is enabled, and there is
sufficient data in the magnetic calibration buffer,
then calibrations should be computed every 30
seconds.
Page 76
SeaTrac Serial Command Interface Reference
Page 77
SeaTrac Serial Command Interface Reference
AHRS_RAW_GYRO_X INT16 The last raw rate of rotation measured around the
X-axis of the gyroscope sensor.
Values are encoded in degrees-per-second.
Page 78
SeaTrac Serial Command Interface Reference
AHRS_RAW_GYRO_Y INT16 The last raw rate of rotation measured around the
Y-axis of the gyroscope sensor.
Values are encoded in degrees-per-second.
AHRS_RAW_GYRO_Z INT16 The last raw rate of rotation measured around the
Z-axis of the gyroscope sensor.
Values are encoded in degrees-per-second.
Page 79
SeaTrac Serial Command Interface Reference
7.3.2. CID_STATUS_CFG_GET
This CID_STATUS_CFG_GET command allows the current configuration for the generation of
automated status messages to be quickly retrieved.
Page 80
SeaTrac Serial Command Interface Reference
7.3.3. CID_STATUS_CFG_SET
The CID_STATUS_CFG_SET command allows quick configuration of the status message output
configuration without the need to read or reload the entire settings structure. However, any
changes made with this command will only apply to the working RAM settings, and will be lost
upon power-down unless they are subsequently with the CID_SETTINGS_SAVE command.
Page 81
SeaTrac Serial Command Interface Reference
All settings are stored within a single “settings record” and at power-up this is loaded from
permanent (non-volatile) EEPROM memory into the working RAM area.
Any changes made to the settings record by the user (through the CID_SETTINGS_SET
command) are always made to the working RAM set and will be lost if the device is powered
down before a CID_SETTINGS_SAVE command is issued to update the EEPROM copy.
When new settings are specified by the CID_SETTINGS_SET command most will be applied
immediately. However, some settings such as those controlling communications baud-rates etc
are only applied when the device is powered up (or restarts via a CID_SYS_REBOOT command).
See the SETTINGS_T structure definition for details of which settings are only applied on power-
up/reboot.
The EEPROM memory used to permanently store the settings information in the beacon
has a lifetime endurance of between 10,000 and 50,000 write cycles, after which its
data retention capabilities may start to degrade (below the guaranteed 5 year period).
For this reason, only store the working RAM settings when required with the
CID_SETTINGS_SAVE command. When designing a control system, ensure that
settings are only stored infrequently and when needed (i.e. not on a periodic basis that
may reduce operating life).
7.4.1. CID_SETTINGS_GET
The CID_SETTINGS_GET command is issued to read back the settings record from working RAM
containing the values currently in use.
Page 82
SeaTrac Serial Command Interface Reference
7.4.2. CID_SETTINGS_SET
The CID_SETTINGS_SET command is issued to update the values of the working RAM settings
and apply the new values.
This command updates the entire contents of the settings record, so for modification of settings
it is recommended to first use CID_SETTINGS_GET command to read the current settings record,
then modify and resend this.
This command does not save the new settings into permanent EEPROM storage and so
changes made will be lost if the device is powered down or rebooted.
To store changes after the set command, use the CID_SETTINGS_SAVE command.
Not all settings will be applied after the set command is issued. Specifically
communication baud-rate settings will only be applied when the device is next power
up, or a CID_SYS_REBOOT command is issued.
See the SETTINGS_T structure definition for details of which settings are only applied
on power-up/reboot.
Page 83
SeaTrac Serial Command Interface Reference
7.4.3. CID_SETTINGS_LOAD
This CID_SETTINGS_LOAD command causes the beacon to re-load the working RAM settings
from the EEPROM storage and apply them. Any previous changes made to the working RAM
settings that have not been stored with the CID_SETTINGS_SAVE will be lost.
Not all settings will be applied after the load operation completes. Specifically
communication baud-rate settings will only be applied when the device is next power up,
or a CID_SYS_REBOOT command is issued.
See the SETTINGS_T structure definition for details of which settings are only applied on
power-up/reboot.
Page 84
SeaTrac Serial Command Interface Reference
7.4.4. CID_SETTINGS_SAVE
The CID_SETTINGS_SAVE command is sent to save the current working RAM settings into
permanent storage, ensuring they are used next time the beacon is powered up.
The beacon uses EEPROM memory to permanently store the settings information, but
this has a lifetime endurance of between 10,000 and 50,000 cycles, after which its
data retention capabilities may start to degrade (below the guaranteed 5 year period).
For this reason, the beacon settings system allows quick and real-time parameter
changes to be made into working RAM, and only stored when required with the
CID_SETTINGS_SAVE command.
When designing a control system, ensure that settings are only stored infrequently and
when needed (i.e. not on a periodic basis that may reduce operating life).
If the communications baud-rate settings are accidentally changed, saved and the
device rebooted, it may not be possible to re-establish serial communications (without
trying all available baud rates).
An alternative is to use the magnetic reset-to-defaults function supported by the
beacon (although this will also reset calibration data) – see the beacon user manual for
further details.
Page 85
SeaTrac Serial Command Interface Reference
7.4.5. CID_SETTINGS_RESET
The CID_SETTINGS_RESET command is used to reset the working RAM settings back to their
factory default values, and store the default values back into EEPROM memory.
The beacon uses EEPROM memory to permanently store the settings information, but
this has a lifetime endurance of between 10,000 and 50,000 cycles, after which its
data retention capabilities may start to degrade (below the guaranteed 5 year period).
When designing a control system, ensure that settings are only reset infrequently and
when needed (i.e. not on a periodic basis that may reduce operating life).
Not all settings will be applied after the load operation completes. Specifically
communication baud-rate settings will only be applied when the device is next power
up, or a CID_SYS_REBOOT command is issued.
See the SETTINGS_T structure definition for details of which settings are only applied
on power-up/reboot.
Page 86
SeaTrac Serial Command Interface Reference
The following calibration commands have been provided to allow application and developers easy
access to sensor calibration functions.
7.5.1. CID_CAL_ACTION
The Calibration Action command should be used at various times by external calibration
applications and algorithms to instruct to beacon to perform operations related to one of its on-
board sensors.
Page 87
SeaTrac Serial Command Interface Reference
CAL_ACC_CALC This action should be called once new sensor MIN and
MAX limit values have been obtained by rotation during
a accelerometer calibration. When issued, the beacon
calculates the new calibration coefficients from the
measured limits (CID_SETTINGS_SAVE should then be
issued to store the new calibration to EEPROM
memory).
CAL_MAG_CALC Once the magnetic buffer has been filled, calling this
action will calculate and apply a new magnetometer
calibration for Hard and Soft Iron compensation
(CID_SETTINGS_SAVE should then be issued to store
the new calibration to EEPROM memory).
Page 88
SeaTrac Serial Command Interface Reference
7.5.2. CID_AHRS_CAL_GET
The CID_AHRS_CAL_GET command allows the current calibration coefficients in use by the AHRS
system to be quickly retrieved.
Page 89
SeaTrac Serial Command Interface Reference
7.5.3. CID_AHRS_CAL_SET
The CID_AHRS_CAL_SET command is used to allow direct updating of the AHRS sensor
calibration coefficients without the need to read or reload the entire settings structure. However,
any changes made with this command will only apply to the working RAM settings, and will be
lost upon power-down unless they are subsequently with the CID_SETTINGS_SAVE command.
Page 90
SeaTrac Serial Command Interface Reference
With the exception of the CID_XCVR_ANALYSE message, all other messages are
generated only when the appropriate enabling flag is set in the acoustic transceiver
settings – see CID_SETTINGS_SET.
7.6.1. CID_XCVR_ANALYSE
The CID_XCVR_ANALYSE command is sent to instruct the transceiver to perform a background
noise analysis of the receiver, and report its findings.
On receiving the command, the transceiver will stop any reception activity in progress, then
listen to the main receiver transducer for 0.5 seconds to determine noise levels. Once the test
in finished, the transceiver will return to the Idle state waiting for a new reception to commence.
Page 91
SeaTrac Serial Command Interface Reference
Page 92
SeaTrac Serial Command Interface Reference
7.6.2. CID_XCVR_TX_MSG
The CID_XCVR_TX_MSG status message is generated when the acoustic transceiver is instructed
to send a message to another beacon.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on protocol handlers or acoustic activity
triggering a transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 93
SeaTrac Serial Command Interface Reference
7.6.3. CID_XCVR_RX_ERR
The CID_XCVR_RX_ERR status message is generated when the acoustic transceiver has
encountered an error while trying to receive an acoustic message, or wait for a request response
to be received.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Faint degraded or noisy acoustic signals may lead to data corruption on the receiver,
which is the most common cause of CST_XCVR_CSUM_ERROR messages being
generated.
Page 94
SeaTrac Serial Command Interface Reference
Page 95
SeaTrac Serial Command Interface Reference
7.6.4. CID_XCVR_RX_MSG
The CID_XCVR_RX_MSG status message is generated when the acoustic transceiver has
received a valid general message from another beacon that does not require a reply or
acknowledgment. After issuing this status message, the acoustic message is passed to the
appropriate protocol handler in the acoustic protocol stack, which may generate further
messages.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 96
SeaTrac Serial Command Interface Reference
7.6.5. CID_XCVR_RX_REQ
The CID_XCVR_RX_REQ status message is generated when the acoustic transceiver has received
a valid request message from another beacon that will require a reply constructing and
transmitting back. After issuing this status message, the acoustic message is passed to the
appropriate protocol handler in the acoustic protocol stack, which may generate further
messages.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 97
SeaTrac Serial Command Interface Reference
7.6.6. CID_XCVR_RX_RESP
The CID_XCVR_RX_RESP status message is generated when the acoustic transceiver has
received a valid response to a request message it transmitted earlier. After issuing this status
message, the acoustic message is passed to the appropriate protocol handler in the acoustic
protocol stack, which may generate further messages.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 98
SeaTrac Serial Command Interface Reference
7.6.7. CID_XCVR_RX_UNHANDLED
The CID_XCVR_RX_UNHANDLED status message is generated when the acoustic transceiver has
received a message with a payload protocol identifier that it does not know how to handle within
its acoustic protocol stack.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_DIAG_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 99
SeaTrac Serial Command Interface Reference
7.6.8. CID_XCVR_USBL
The CID_XCVR_USBL status message is generated when the acoustic transceiver has received
a message that contains a USBL signal, from which incoming signal angle information can be
computed. The message contents are design to assist with diagnosing the validity of acoustic
signals, and debug causes of reception/decoding failure.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_USBL_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
The CID_XCVR_USBL message is large in size (typically 461 bytes) so suitable memory
buffering should be allocated when decoding.
Sending this message over a slow serial communications link may degrade the
performance of the beacon.
XCOR_DETECT UINT16 The correlation sample number where the first peak
of USBL signal was found.
Page 100
SeaTrac Serial Command Interface Reference
SIGNAL_FIT_ERROR FLOAT The fit error value returns a number that indicates
the quality of fit (or confidence) of the signal
azimuth and elevation values from the timing and
phase-angle data available.
Page 101
SeaTrac Serial Command Interface Reference
7.6.9. CID_XCVR_FIX
The CID_XCVR_FIX status message is generated when the acoustic transceiver has received a
message from which information about the remote beacons position can be determined.
In the case of MSG_RESPU and MSG_RESPX messages, these are sent in response to a request
message, and because round-trip timing is then available a range can be determined to the
remote beacon, and combined with incoming signal angles, a relative position estimate can be
made.
However, for MSG_OWAYU messages no such timing information in available, so only incoming
signal angle information is available in the fix message.
Messages with the MSG_RESPX type also contain an additional field specifying the depth of the
remote beacon. From this information an enhanced vertical position fix can be computed.
For message types of MSG_RESP, no USBL signal information is available, so only ranging
information can be computed.
Messages types of MSG_OWAY do not provide USBL information, or allow for timing to be
performed, so Fix messages will not be generated on their reception.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
This message is generated only when the XCVR_FIX_MSGS flag is specified in the
acoustic transceiver SETTINGS_T structure – see CID_SETTINGS_SET.
Page 102
SeaTrac Serial Command Interface Reference
7.6.10. CID_XCVR_STATUS
The CID_XCVR_STATUS command can be used to determine the current operating state of the
acoustic transceiver modules.
It is particularly useful to use prior to issuing other commands that may start transmissions (i.e.
CID_PING_SEND, CID_ECHO_SEND etc.) to check that the transceiver is currently in the IDLE
state and can perform the operation.
Page 103
SeaTrac Serial Command Interface Reference
Unlike other protocols, PING messages do not carry any payload information making them the
shortest messages possible. This in turn leads to least power consumption for battery powered
operations, and the fastest polling speed in networked or navigation systems.
Once the beacon is correctly configured, a PING operation is started by sending the
CID_PING_SEND command.
Page 104
SeaTrac Serial Command Interface Reference
8.1.1. CID_PING_SEND
The CID_PING_SEND command is issued to perform an acoustic “ping” on another beacon, from
which its range and position can be determined.
For positioning, acoustic PING messages are the shortest of all the protocols available, requiring
the least power consumption on the transmitter and allowing the fastest operation when polling
round a network.
DEST_ID BID_E The ID code of the beacon to send the Ping to, and
receive position and ranging information for.
Valid values are form 1 to 15.
Page 105
SeaTrac Serial Command Interface Reference
BEACON_ID BID_E The ID code of the beacon that the command was
sent to.
Valid values are form 1 to 15.
Page 106
SeaTrac Serial Command Interface Reference
8.1.2. CID_PING_REQ
The CID_PING_REQ status message is generated when the beacon received an acoustic PING
message from the sending beacon. This message is provided by the protocol-handler in the
beacon for information purposes only, and no action or acknowledgment by the external
system/user is required.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
8.1.3. CID_PING_RESP
The CID_PING_RESP status message is generated by the sending beacon when it receives a
PING response back from the remote (“pinged”) beacon.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
Page 107
SeaTrac Serial Command Interface Reference
8.1.4. CID_PING_ERROR
The CID_PING_ERROR status message is generated when a PING operation is not successful,
usually because a response is not received from the remote interrogated beacon, causing a
timeout.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon that the error applies to
(i.e. the DEST_ID value used in the
CID_PING_SEND command).
Valid values are form 1 to 15.
Page 108
SeaTrac Serial Command Interface Reference
The CID_ECHO_SEND command is used to start an ECHO transmission, where a user specified
payload of up to 31 bytes is sent to the remote beacon. Upon successful reception, the remote
beacon will then return a response message containing the same payload.
While the acoustic transceiver should receive the response message correctly, and not have to
validate the contents of the response data (guaranteed by the CRC checksum algorithms used),
the longer structures used by the ECHO protocol over the PING protocol allow acoustic channel
characteristics to be evaluated or the effect of Doppler shift on remote beacons.
8.2.1. CID_ECHO_SEND
The CID_ECHO_SEND command is issued to send a packet of data to another remote beacon,
and have this beacon return (or echo) the data back, also allowing its range and position to be
determined.
When sending ECHO data, be aware that larger quantities of data will take longer to
send (by 80ms per byte), and during this time the receiver may become more
susceptible to errors caused by Doppler shift or other interference, and the statistical
probability of the CRC16 checksum algorithm (used by the acoustic transceiver)
uniquely validating the message content becomes reduced.
When testing the acoustic link, it is recommended to use data lengths of 16 bytes or
less if problems with communications are observer.
DEST_ID BID_E The ID code of the beacon to send the Echo request
to, and receive position and ranging information
for.
Valid values are form 1 to 15.
Page 109
SeaTrac Serial Command Interface Reference
ECHO_DATA UINT8[x] The array of data that should be sent in the Echo
acoustic packet, where “x” is the value specified in
ECHO_LEN.
BEACON_ID BID_E The ID code of the beacon that the command was
sent to.
Valid values are form 1 to 15.
Page 110
SeaTrac Serial Command Interface Reference
8.2.2. CID_ECHO_REQ
The CID_ECHO_REQ status message is generated when the beacon received an acoustic ECHO
message from the sending beacon. This message is provided by the protocol-handler in the
beacon for information purposes only, and no action or acknowledgment by the external
system/user is required.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
Page 111
SeaTrac Serial Command Interface Reference
8.2.3. CID_ECHO_RESP
The CID_ECHO_RESP status message is generated by the sending beacon when it receives an
ECHO response back from the remote beacon. The payload of the response message should
carry a duplicate copy of the data that was transmitted with the CID_ECHO_SEND command.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
ECHO_LEN UINT8 The number of bytes received back from the remote
beacon in the Echo acoustic packet.
Valid values are from 0 to 31.
Page 112
SeaTrac Serial Command Interface Reference
8.2.4. CID_ECHO_ERROR
The CID_ECHO_ERROR status message is generated when an ECHO operation is not successful,
usually because a response is not received from the remote interrogated beacon, causing a
timeout.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon that the error applies to
(i.e. the DEST_ID value used in the
CID_ECHO_SEND command).
Valid values are form 1 to 15.
Page 113
SeaTrac Serial Command Interface Reference
The DAT protocol is deliberately basic in its implementation, allowing system developers to
decide how to format and interpret the data packets – for example implementing “port” numbers
(similar to the UDP protocol), sequence pointers etc.
By implementing a simple controlling state machine, developers can use the ACK/ACK_USBL
send modes to determine the presence of the remote beacon and remotely retrieve data.
CID_DAT_RECEIVE messages will be returned to indicate data has been received at either end
of the link, or CID_DAT_ERROR messages to indicate undelivered data in the case of a timeout
or other reception error occurring.
At either receiving end, data is not buffered, but output with a CID_DAT_RECEIVE message as
it arrived, again allowing system developers to handle the data in the best way for their
application.
When sending DAT data, be aware that larger quantities of data will take longer to
send (by 80ms per byte), and during this time the receiver may become more
susceptible to errors caused by Doppler shift or other interference, and the statistical
probability of the CRC16 checksum algorithm (used by the acoustic transceiver)
uniquely validating the message content becomes reduced.
As mentioned above, the simplicity of the DAT protocol also leads to limitations if
trying to send larger amounts of data (across several packets) and verify successful
reception of the data in sequence, resending missing packets.
Developers may choose to implement their own protocol handling technique using the
DAT commands, however the DEX protocol has been developed using concepts similar
to those found in the TCP protocol to provide bi-directional data exchange with a
timeout-retry mechanism built into the protocol handler. DEX communications occur
through buffered ‘sockets’ defined between beacons, with port numbers allowing
different channels of data to be send.
For further details see section 8.5 on page 134.
Page 114
SeaTrac Serial Command Interface Reference
8.3.1. CID_DAT_SEND
The CID_DAT_SEND command is issued to send a packet of data to another remote beacon,
optionally requesting that the remote beacon acknowledge reception of the data.
If the command requires an acknowledgement (ACK), then at some point later upon reception
of the response message a CID_DAT_RECEIVE message will be output containing the ACK flag
and any additional remotely queued data that has been transmitted back.
When sending DAT data, be aware that larger quantities of data will take longer to
send (by 80ms per byte), and during this time the receiver may become more
susceptible to errors caused by Doppler shift or other interference, and the statistical
probability of the CRC16 checksum algorithm (used by the acoustic transceiver)
uniquely validating the message content becomes reduced.
DEST_ID BID_E The ID code of the beacon to send the DATA to.
Valid values are form 0 to 15.
Page 115
SeaTrac Serial Command Interface Reference
PACKET_DATA UINT8[x] The array of data that should be sent in the DAT
acoustic packet, where “x” is the value specified in
PACKET_LEN.
BEACON_ID BID_E The ID code of the beacon that the command was
sent to.
Valid values are form 1 to 15.
Page 116
SeaTrac Serial Command Interface Reference
8.3.2. CID_DAT_RECEIVE
The CID_DAT_RECEIVE status message is generated when the beacon received a DAT protocol
data packet from another beacon.
Additionally, this message will be issued upon reception of an acknowledgement response back
from a remote beacon if the CID_DAT_SEND command specified its MSG_TYPE value to be either
MSG_RESP, MSG_RESPU or MSG_RESPX. In this case, if the remote beacon had any data
queued, it will also have been transmitted and is output with this message.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
The receiving beacon (generating this message) will automatically handle generation of
requested ACK messages if required. Beyond handling the data in the reported packet
not further interaction is required with the external system/user.
Page 117
SeaTrac Serial Command Interface Reference
8.3.3. CID_DAT_ERROR
The CID_DAT_ERROR status message is generated when a DAT operation is not successful,
usually because a response is not received from the remote interrogated beacon, causing a
timeout.
This message will only be generated if the CID_DAT_SEND command specified its MSG_TYPE
field to be MSG_REQ, MSG_REQU or MSG_REQX, as only these modes allow the remote beacon
to report back its status.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon that the error applies to
(i.e. the DEST_ID value used in the CID_DAT_SEND
command).
Valid values are form 1 to 15.
Page 118
SeaTrac Serial Command Interface Reference
8.3.4. CID_DAT_QUEUE_SET
The CID_DAT_QUEUE_SET command is used to store (queue) a single packet of data in the
beacon, that will be held until an acoustic CID_DAT_SEND message from another beacon is
received that requires a response from a specific.
The DAT queue only holds one packet. Subsequent CID_DATA_QUEUE_SET commands
will overwrite any previously un-transmitted data.
PACKET_DATA UINT8[x] The array of data that should be sent in the DAT
acoustic packet, where “x” is the value specified in
PACKET_LEN.
Page 119
SeaTrac Serial Command Interface Reference
8.3.5. CID_DAT_QUEUE_CLR
The CID_DAT_QUEUE_CLR command is used to clear any packed that has been queued for
remote retrieval by the DAT protocol, using the CID_DATA_QUEUE_SET command.
Page 120
SeaTrac Serial Command Interface Reference
8.3.6. CID_DAT_QUEUE_STATUS
The CID_DAT_QUEUE_STATUS command is used to determine if any packet is queued and
waiting for remote retrieval by the DAT protocol in response to a CID_DAT_SEND command.
The number of bytes in the packet payload is returned in response to this command, and when
the packet has been delivered, this value is reported as 0, indicating empty (and another packet
can be queued).
Page 121
SeaTrac Serial Command Interface Reference
As standard, the NAV protocol uses enhanced USBL fixes where the remote beacons depth is
transmitted in the response message. From this, USBL beacons can improve the computed
vertical position solution.
8.4.1. CID_NAV_QUERY_SEND
The CID_NAV_QUERY_SEND command is issued to request the specified remote beacon respond
with the requested information.
Regardless of which information if requested, the response contains an enhanced USBL message,
where the remote depth sensor reading is encoded to a resolution of 1m, and this is used to
compute the vertical Z-axis depth from surface of the position fix. The only exception to this is
when remote Depth information is requested, then this value (to 0.1m resolution) is used for
the Z-axis depth fix.
By default the NAV protocol uses an enhanced USBL fix that returns the remote
beacons depth to a resolution of 1m, and this is used to augment the position fix.
However, if the QRY_DEPTH bit is specified in the QUERY_FLAGS field, the remote
beacon will return the depth to an resolution of 0.1m and use this value instead in the
position fix as well as returning it in response message REMOTE_DEPTH field and FIX
structure.
Page 122
SeaTrac Serial Command Interface Reference
DEST_ID BID_E The ID code of the beacon to send the Echo request
to, and receive position and ranging information
for.
Valid values are form 1 to 15.
BEACON_ID BID_E The ID code of the beacon that the command was
sent to.
Valid values are form 1 to 15.
Page 123
SeaTrac Serial Command Interface Reference
8.4.2. CID_NAV_QUERY_REQ
The CID_NAV_QUERY_REQ status message is generated when the beacon received an acoustic
NAV message from the sending beacon. This message is provided by the protocol-handler in the
beacon for information purposes only, and no action or acknowledgment by the external
system/user is required.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
Page 124
SeaTrac Serial Command Interface Reference
8.4.3. CID_NAV_QUERY_RESP
The CID_NAV_QUERY_RESP status message is generated when the beacon receives back a
message from the remote beacon in response to a CID_NAV_QUERY_SEND command.
In the response, the requested remote beacons information specified by the QUERY_FLAGS
parameter is encoded, and output via this message.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
Note: By default the NAV protocol uses an enhanced USBL fix that returns the remote
beacons depth to a resolution of 1m, and this is used to augment the position fix.
However, if the QRY_DEPTH bit is specified in the sent QUERY_FLAGS field, the remote
beacon will return the depth to an resolution of 0.1m and use this value instead in the
position fix as well as returning it in the REMOTE_DEPTH field and FIX structure.
Depth Fields
If the message QUERY_FLAGS parameter contains the QRY_DEPTH bit (see NAV_QUERY_T),
then the following fields are sequentially appended to the message record…
Supply Fields
If the message QUERY_FLAGS parameter contains the QRY_SUPPLY bit (see NAV_QUERY_T),
then the following fields are sequentially appended to the message record…
Page 125
SeaTrac Serial Command Interface Reference
Temperature Fields
If the message QUERY_FLAGS parameter contains the QRY_TEMP bit (see NAV_QUERY_T), then
the following fields are sequentially appended to the message record…
Attitude Fields
If the message QUERY_FLAGS parameter contains the QRY_ATTITUDE bit (see NAV_QUERY_T),
then the following fields are sequentially appended to the message record…
Page 126
SeaTrac Serial Command Interface Reference
8.4.4. CID_NAV_ERROR
The CID_NAV_ERROR status message is generated when an NAV operation is not successful,
usually because a response is not received from the remote interrogated beacon (causing a
timeout) or a malformed payload has been decoded.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon that the error applies to
(i.e. the DEST_ID value used in the
CID_ECHO_SEND command).
Valid values are form 1 to 15.
Page 127
SeaTrac Serial Command Interface Reference
8.4.5. CID_NAV_REF_POS_SEND
The CID_NAV_REF_POS_SEND message is used to broadcast the reference position of the local
beacon (defined by Latitude and Longitude) to all other beacons capable of receiving the
message.
This message allows a USBL beacon forming part of an acoustic tracing system, to occasionally
transmit its own position as a world referenced coordinate to all other surrounding beacons.
If these beacons have been receiving position updates from the CID_NAV_BEACON_POS_SEND
command, then the information sent here then allows them to compute their own (and other
beacons) world position from the previously transmitted relative NED co-ordinates (as the
latitude/longitude specifies the origin of the relative NED values).
POSITION_LATITUDE INT32 The latitude part of the local beacons position, used
as the reference position from which relative
Northing/Easting/Depth positions are based.
Page 128
SeaTrac Serial Command Interface Reference
8.4.6. CID_NAV_REF_POS_UPDATE
The CID_NAV_REF_POS_UPDATE message is generated when the beacon receives acoustic
information sent from another beacon with the CID_NAV_REF_POS_SEND command.
On reception of the message, the acoustic payload is decoded and the transmitted
Latitude/Longitude position for the specified beacon is output from the serial port.
The connected host system may then use this information to convert previously send NED
coordinates to world coordinates by treading the latitude and longitude as the original of the
NED grid.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon this position refers to.
Valid values are form 1 to 15.
Page 129
SeaTrac Serial Command Interface Reference
8.4.7. CID_NAV_BEACON_POS_SEND
The CID_NAV_BEACON_POS_SEND message is used to broadcast a position of a beacon (defined
as Northing, Easting and Depth) to all other beacons capable of receiving the message.
This message allows a USBL beacon forming part of an acoustic tracing system, to perform
sequential Queries or Pings to the other remote beacons that require tracking (using command
like CID_NAV_QUERY_SEND or CID_PING_SEND).
On successful reception of a response and computation of a position Fix, the USBL beacon can
use this command to re-broadcast the computed NED position of the remote beacon (relative to
the USBL head) to ALL the other beacons, who can in-turn update their local hardware (i.e. Diver
display, AUV navigation system etc)
Additional use of the CID_NAV_POS_SEND command allows the USBL beacons latitude and
longitude coordinates to also be transmitted, which are the reference point for
Northing/Easting/Depth positions to be world referenced.
BEACON_ID BID_E The ID code of the beacon this position refers to.
Valid values are form 1 to 15.
Page 130
SeaTrac Serial Command Interface Reference
Page 131
SeaTrac Serial Command Interface Reference
8.4.8. CID_NAV_BEACON_POS_UPDATE
The CID_NAV_BEACON_POS_UPDATE message is generated when the beacon receives acoustic
information sent from another beacon with the CID_NAV_BEACON_POS_SEND command.
On reception of the message, the acoustic payload is decoded and the transmitted
Northing/Easting/Depth position for the specified beacon is output from the serial port.
The connected host system may then use this information to update tracking tables/records as
required for all other beacons in the network being interrogated by the USBL controller.
This message is a status message that may be sent by the beacon at any time (not in
response to a command message) depending on acoustic activity triggering a
transceiver event.
BEACON_ID BID_E The ID code of the beacon this position refers to.
Valid values are form 1 to 15.
Page 132
SeaTrac Serial Command Interface Reference
Page 133
SeaTrac Serial Command Interface Reference
Buffered sockets, allowing links to be defined between beacon pairs, and data placed
onto the appropriate buffer ready for transfer.
Synchronised retry mechanism, to track which data has been sent and which packets
have failed and need to be resent.
This section is still under construction and will be detailed in the next release of this document.
8.5.1. CID_DEX_CLOSE
8.5.2. CID_DEX_DEBUG
8.5.3. CID_DEX_ENQUEUE
8.5.4. CID_DEX_OPEN
8.5.5. CID_DEX_RESET
8.5.6. CID_DEX_SEND
8.5.7. CID_DEX_SOCKETS
8.5.8. CID_DEX_RECEIVE
Page 134
SeaTrac Serial Command Interface Reference
By orienting the positive Z-axis downwards, positive Yaw angles also match compass
headings, with 0° Yaw occurring when the housing “front” marking aligns with magnetic
north.
Pitch and Roll angles are 0° when gravity is perpendicular to (and below) the horizontal
plane, defined by the XY axis pair.
Page 135
SeaTrac Serial Command Interface Reference
Page 136
SeaTrac Serial Command Interface Reference
Coordinates are relative to the beacon’s position, with the origin being the defined as the
centre of the upper beacon housing bulkhead.
Please note that to comply to the earlier ‘attitude’ definition, positive Z axis directions
are defined as “down” (towards the seabed) when the beacon is mounted in the upright
position shown above.
World coordinates are provided in a Cartesian Northing, Easting and Depth (NED) triplet,
with values stated in metres. Positive values of depth represent a translation towards
the seabed, while negative values represent a translation towards the surface.
Page 137
Distributor…
www.blueprintsubsea.com
Blueprint Subsea,
The Clock Tower Business Centre,
Low Wood, Ulverston, Cumbria, LA12 8LY, UK