Chapter 15. Appendix E – Acoustic Modem link

15.1 Description of Operation

The acoustic data transmission link between an Aquarius and the surface comprises of two nodes; referred to here as a Surface (Ship based Deck Unit or Buoy System) and Bottom (Aquarius or Aquarius) modems. The Bottom modem type and capability varies between Aquarius and Aquarius, but the principles of operation and fault finding are the same.

Each modem, Surface or Bottom, has a unique identification number which is set at the factory; this is rarely used directly. Acoustic modems have a more convenient user configurable Acoustic Modem Address which is used to direct communications to correct nodes.

Each communication node has the concept of Local and Remote: The Local Acoustic Modem Address is the address of the modem at node you are directly interacting with; the Remote Acoustic Modem Address is the address of the modem you wish to communicate with acoustically.

There are two types of acoustic transmission; Commands and Data. Commands are modem only communications pertaining to the operation, configuration and status of the acoustic modems themselves. The system (e.g. Aquarius, Buoy system or Deck unit) attached to a modem that has a Command directed at it is not aware that an acoustic transmission has taken place (and will not wake up if asleep, for example). Data transmissions are acoustic transmissions that require interaction with, or a response from the attached Surface or Bottom systems. Setting a time for the backup burn wire operation, commanding an OBS to perform re-centring, obtaining seismic data from an OBS and an OBS informing a Surface system of a seismic event are all examples of acoustic Data transmissions.

Commands are shorter and more robust acoustic transmissions than Data transmissions. Therefore, it is good practice to make first contact with a deployed OBS with a Command to verify the quality of an acoustic link.

Data transmissions (sent with the MDFT command) are typically much longer than Commands. Each Data transmission frame is split up into multiple sub-frame transmissions, up to 16 per frame. The number of sub-frames required to send a given packet of data depends on the bitrate. Data packets to be transferred between Surface and Bottom nodes are always sized to fit within one acoustic transfer frame, regardless of bitrate. Larger transmissions are split into smaller packets to ensure this.

15.1.1 Modem Configuration

This manual is not intended to serve as a reference for the acoustic modem protocol; a subset of possible configuration options and parameters is included, limited to those which are most likely to require alteration during the operation of the Aquarius and associated systems.

These parameters fall into three categories; Power & Gain, Delay and Bitrate & Retries.

15.1.1.1 Power & Gain

In order for two acoustic modem nodes to communicate, the strength of the acoustic signals they transmit and the sensitivity to incoming signals being received must be appropriate for the parameters of the installation.

15.1.1.1.1 Power

There are two relevant configuration parameters for setting power levels of acoustic transmission in a modem: Start Power Level (SPL) and Telemetry Power Level (TPL). These must be set at an appropriate level for the particular depth of water. It is important to note that more power does not always result in a stronger acoustic link, especially in shallow water scenarios. Higher transmission power increases the likelihood of destructive acoustic reflections and saturation at the receiving node. Instead a sufficient power level should be chosen.

The selection of power parameters should be performed using the OBS Command & Control window for the Surface modem, and the Bottom modem if the OBS has already been deployed. The Acoustic Configuration tab contains controls for setting power, gain and other parameters dependant on depth under Depth Configuration (see Section 7.1.3.3 on page 41).

The depth related power and gain settings should be set Locally in the Bottom OBS node before deployment via the LPC web interface, “Network” tab (see Section 7.2.6).

It is also possible to read and set these parameters manually using the Configuration Status (CS) command (see Section 15.2). This should only be attempted with support from Güralp.

15.1.1.1.2 Gain

In addition, it is possible to set the gain of acoustic signals as they are received at a modem. This is known as the Linear Gain (LG) parameter. It is desirable to set LG as low as possible yet as high as necessary. Too high a gain setting will result in saturation and increased noise (lower signal to noise ratio). Too low a gain will result in a weak acoustic link and, in the worst case, loosing communication with an OBS Bottom node altogether.

The selection of LG should be performed using the Discovery OBS Command & Control window for the Surface modem, and the Bottom modem if the OBS has already been deployed. The Acoustic Configuration tab contains controls for setting power, gain and other parameters dependant on depth under Depth Configuration (see Section 7.1.3.3 on page 41).

The depth related power and gain settings should be set Locally in the Bottom OBS node before deployment via LPC web interface. This is especially important for LG, “Network” tab (see Section 7.2.6).

It is also possible to read and set these parameters manually using the Configuration Status (CS) command (see Section 15.2). This should only be attempted with support from Güralp.

15.1.1.2 Delays

15.1.1.2.1 Receiver Wait

The primary delay parameter, that has the most impact on the success of acoustic transmissions, is Receiver Wait or RXW. RXW defines the amount of time an acoustic modem will wait for a response from the receiving node for.

The correct delay setting depends exclusively on the distance between two communicating acoustic modems (slant range). This is dictated by the installation depth of the OBS, apart from situations which require a large ratio of lateral distance to depth (these should be avoided as much as possible).

The depth related RXW, along with NPL, TPL and SPL, should be set Locally in the Bottom OBS node before deployment via LPC web interface, “Network” tab (see Section 7.2.6).

In the surface modem RXW should be set, along with NPL, TPL and SPL, in the depth configuration section of the Acoustic Configuration tab of the Discovery Command & Control window (see Section 7.1.3.3 on page 41). Using the same tab of the OBS Command & Control widget it is also possible to change RXW in the bottom modem via acoustic command.

15.1.1.2.2 Local Modem Delays

Local modem delays define the timings of the interactions between a modem and the attached system (Surface or Bottom/OBS). These delays only impact Data transmissions with the MDFT command. None of the local modem delays should require alteration during the deployment, operation or recovery of an Aquarius. Changing these parameters should only be attempted with guidance from Güralp.

Data Delay or DD defines the time delay between the end of one sub-frame transmission and the beginning of the next.

Modem Delay or MD defines the maximum time that the recipient modem of a request for data will wait before sending a reply. This allows the attached system to provide data to the modem for the response. It takes effect when the responding modem does not already have data to send.

Uplink Delay or UD defines the time that the recipient modem of a request for data will wait before sending a reply in the case of data having already been loaded for the response.

Inter Character Time or ICT is the timeout implemented by the recipient modem of a request for data before automatically sending the response. It is applied after the first character is sent serially from the associated system.

All of the local modem delays for the Surface and Bottom modems can be read and set via the Modem Delays section of the Acoustic Configuration tab in the OBS Command & Control window in Discovery.

It is also possible to read and set these parameters manually using the Modem Status (MS) command (see Section 15.2). This should only be attempted with support from Güralp.

15.1.1.3 Bitrate & Retries

15.1.1.3.1 Bitrate

For Data transmissions it is possible to define the bitrate (TS) that data sub-frames will be transmitted at. Higher bitrates allow a given packet of data to be transferred faster and with fewer sub-frames, but in certain conditions it increases the risk of the recipient modem not successfully receiving the sub-frame and discarding it.

The Data transmission bitrate should be set in via the Acoustic Baud Rate section in the Acoustic Configuration tab of the OBS Command & Control window (see Section 7.1.3.3 on page 41). The optimal bitrate setting is the highest value that only infrequently causes lost sub-frames.

It is also possible to set the bitrate manually by changing the Telemetry Scheme or TS parameter using the MS command (see Section 15.2).

15.1.1.3.2 Master Retries

In the case of Data transmission sub-frames not successfully received following a request for data, the requesting modem can re-request specific failed sub-frames. This feature allows the data bitrate to be increased without loss of connectivity.

This is set via the Master Retries (MR) parameter (not to be confused with the MR or Measure Range command) using the MS command (see Section 15.2). It is set to an appropriate value by default and should not require alteration.

15.2 Sonardyne Debugger

Discovery offers a useful tool for troubleshooting called “Sonardyne Debugger”. It allows to test the functionalities of the acoustic modem.

In Discovery select the Aquarius and click on “Edit” → “Sonardyne Debugger” to launch the interface.

The “Sonardyne Debugger” can be used either in a Discovery installed in a PC or a Deck Unit connected via serial to a surface modem or in a remote Discovery, connected via TCP/IP to the Discovery connected via serial to the surface modem (i.e. Discovery on shore that connects via satellite link to the Discovery installed on the buoy PC).

The top section of the window is used to establish the serial connection to the modem and the TCP/IP connection to the Discovery physically connected to the modem. The following screenshot shows a configuration in a Discovery in a deck unit, so connected by serial to the surface modem. The hostname used in this case is “localhost”. Press the “Connect” button to establish a connection to the local Discovery at IP 127.0.0.1. Wait for the status at the bottom-left of the window to be Ready.

Use the drop down menus at the top-left to select the PC serial ports connected to the “Command” and “Data” ports of the surface modem. These ports are used in the modem for console commands and data transmission respectively.

In case of a Sonardyne Debugger in a remote Discovery, insert the WAN or LAN IP address of the PC where the Discovery, physically connected to the surface modem, is installed and click the “Connect” button. As shown in the screenshot below, both the serial ports drop down menu will be blanked.

Type in the acoustic address of the remote acoustic modem.

After this, press the “Init” button to initialise the surface acoustic modem. Only after these steps the end user can start sending commands.

Manual commands can be sent using the field at the top-right. Click on “Cmd” button to send the command.

For quick access to most common commands use the buttons below:

• MR: Measure Range.

• CS: Configuration Status.

• MS: Modem Status.

The bottom panel shows commands sent and received. Each line is marked with a letter that distinguishes the type of instruction:

• T: Command transmitted to the “Command” port.

• C: Answer from the surface modem received on the “Command” port.

• D: Data received on “Data” port.

More details on console output are available in Section 15.3.

15.3 Troubleshooting

In the case of a suspected poor acoustic link, a methodical approach is required to ascertain the cause and any potential remedies. This section assumes that the Bottom modem is attached to a deployed OBS and the Surface modem is attached to a suitable deck/topside unit and suspended in water.

Before beginning to troubleshoot, first confirm that the Surface modem/transducer can be communicated with. To verify the connection to the Surface modem:

• Ensure the acoustic modem driver IP address is correct (“localhost” if the Surface modem is physically connected) and click “Connect”. This connects to the driver which will directly interact with the acoustic modem. If the status bar indicates Network Error then ensure the correct acoustic modem driver address before proceeding.

• Ensure the serial port configuration for the two acoustic modem connections is correct (see Section 15.2).

• Ensure the Remote acoustic modem address of the OBS modem is shown correctly in the remote modem address field. If it is not, correct it.

• Click the “Init” button. This will initialise, or reinitialise, the Local Surface modem. At this point the status bar should display Ready. If it does not, verify all relevant physical connections, network connections, serial ports and addresses.

In order to confirm the operation of the Surface modem, set its power parameters to suitable for air and initiate acoustic transmissions. It should be possible to hear the transducer. If no audible signal can be detected from the Surface modem transducer, verify all relevant physical connections, power, network connections, serial ports and addresses.

If the Surface modem appears to operate correctly, lower it into the water to circa 10 meters and attempt to communicate with the OBS Bottom modem.

15.3.1 Send a short Command

When a suspected acoustic transmission problem occurs, start by attempting to send a short and simple Command. These are significantly more likely to succeed than Data transmissions.

The MR command (Measure Range) is recommended as the shortest and most likely acoustic transmission to successfully complete a round trip. This removes dependence on correctly set Modem Status Parameters (including TS, DD, MD, ICT and UD) and simplifies configuration efforts to Configuration Status Parameters (such as SPL, TPL, LG and RXW). MR is not the sole Command that serves this purpose.

A MR command can be sent from the Sonardyne Debugger found in Discovery (see Section 15.2). It can be sent by typing the following command string into the custom command field:

<MR:aaaa;W1

[where aaaa is the remote modem acoustic address of the node you are attempting to communicate with]

Alternatively, for convenience, the Remote modem “MR” button is provided in the Sonardyne Debugger interface to send an MR command to the Remote Modem Address set and initialised in the Local acoustic modem driver.

If successful, the MR command will return with the round-trip time (in microseconds) as a parameter:

>MR:aaaa;R123456

If you do not receive a response containing a valid, non-zero, round-trip time, then the MR command has failed (even if no explicit error is given).

It is possible that the recipient modem may be in a low power sleep mode. If this is the case, the very first (and only the first) Command sent may fail. The addition of W1 in a command instructs the modem to wake up.

15.3.1.1.1 Command Failure

If this lightweight Command has failed to yield a successful reply, the TPL, SPL, NPL, LG, and RXW parameter values should be verified as correct for the deployment depth.

If the acoustic link state of health bar at the bottom of the Command & Control window (or elsewhere) is displaying recent values for SNR and DBV, these can indicate whether the depth related parameters require alteration. It also implies that the Bottom modem is receiving a transmission and responding. If DBV is high, this indicates the transmission power of the Bottom modem is too high or the LG of the Surface modem is too high, or both. These can be changed with the Depth Configuration section in the Acoustic Configuration tab of the Command & Control window. Experiment by changing parameters in the Remote/Bottom or Surface/Local modems individually and, if necessary, change the parameters in both.

If the acoustic link state of health bar indicates low signal DBV or does not indicate any recent state of health information, then it is likely that the depth related parameters are set too shallow. Experiment by increasing the depth configuration in the Remote/Bottom or Surface/Local modems individually and, if necessary, change the parameters in both.

In the case where DBV acoustic diagnostic values appear to be healthy yet SNR values appear low, it is possible that noise from the ship is interfering. Try to lower the Surface modem lower to reduce noise or move to a less noisy area of the ship (i.e. far from the engine), or if other acoustic devices are on, ask to switch them off.

If, after increasing/decreasing depth parameters in both modems, it is still not possible to successfully send and receive an MR (or other lightweight) Command, it is likely that the distance between the two modems is too great. If the depth of the OBS is not believed to be the problem, then the lateral distance away from the position of the OBS is likely to be the cause. All acoustic modem transducers have an operating cone (±40° for the directional transducers, ±120° for the omnidirectional transducers), outside of which their effectiveness is diminished. Attempt to move closer to the OBS and retry.

15.3.2 Read Modem Status

If a lightweight Command is successfully transmitted and received, then the next step is to obtain more detailed information from the Bottom acoustic modem. This will further test the viability of the acoustic link whilst still limiting the range of relevant configuration parameters.

From the Sonardyne Debugger window, send a request for the Configuration Status parameter values by either clicking the Remote modem “CS” button, or sending the following Command:

<CS:aaaa;W1

[where aaaa is the remote modem address of the node you are attempting to communicate with]

Correct responses will follow this format:

>CS:aaaa,TATnnn,BLKnnn,RXWnnnn,TXWnnn,NPLnnn,TPLnnn,LGnn,CISn,ATn,
ECn,MEn,RSPn,PPRn,Rnnnnnnn
[XCnn,SNRnn,DBV-n,TEL;TCSn;RPSKVn_nnn,FEC0;0;0]

Erroneous responses may contain “NO_REPLY”:

>CS:aaaa,NO_REPLY

This indicates that no acoustic signal was received from the other/Bottom acoustic node within the Receiver Wait Time (RXW). It is not possible to infer whether the original transmission was received by the Bottom or whether the Bottom modem attempted to transmit. Therefore, the configuration of both acoustic modems must be investigated.

Erroneous responses may also contain “NO_DATA”:

>CS:aaaa,NO_DATA or >CS:aaaa,TATnnn,NO_DATA,RXWnnnn,TXWnnn,etc…

In this case the Bottom acoustic modem has received the initial CS command and attempted to respond. However, the acoustic transmission from Bottom to Surface was not successful. The most likely cause is improper configuration of the Bottom acoustic modem.

The procedure for improving the strength of the acoustic link is the same as for the lightweight command example given above. Ensure that appropriate power, gain, RXW values are set in both modems.

15.3.3 Get OBS System Information

If the previous troubleshooting procedures have succeeded, it is known that the acoustic link is strong enough to allow the two modem nodes to communicate. The parameters relevant to both Command and Data transmissions have been validated. From here, the next step is ensuring that the acoustic link is viable for transmitting longer Data frames. There is a subset of acoustic modem parameters that affect Data transmissions specifically.

From the Post Deploy tab of the OBS Command & Control window, click either the “Get Aquarius ID” or “Get SEED ID” buttons. These will send an MDFT frame with a request for data (the Host Name or the SEED network and station codes respectively). The requested information should be returned by the OBS system in an MDFT frame.

Following a successful “Get ID” operation, an identification string should be shown in the Post Deploy tab. If an ID is obtained, it is advisable to carry the operation a further 5 – 10 times to ensure that the acoustic link is performing adequately with minimal failed transmissions.

15.3.3.1.1 System Information Request Failure

If it not possible to retrieve a system identifier (or there is an unacceptable failure rate), then begin verifying relevant parameters. There are a number of acoustic modem parameters that directly impact on the success of Data transmissions.

If the preceding Command based troubleshooting procedures have been followed, MDFT “NO_REPLY” and “NO_DATA” responses should not occur. If they do, the preceding troubleshooting sections should be repeated to verify correct power, gain and Receiver Wait parameter values.

Successful MDFT response without data:
The MDFT transmission may complete successfully (as far as the modems are concerned) without transmitting the anticipated data payload. In the modem debugging window (Sonardyne Debugger) this would look like:

<MDFT:aaaa;W1

>[MOD:TX;15;MST1]

>[MOD:RX;15,FROM;5110
[XC86,SNR15,DBV-11,TEL;TCS1;RPSKV2_100,FEC0;0;0;0;0]
,MY_ACKS;8000]

>[MOD:STATUS;16,ID;11]

>[MOD:THEIR_ACKS;8000]

>[MOD:DONE]

>MDFT:5110,LDA0,RDA0,DC0

Here the transmission completes without any acoustic link errors, but identifying information may not be shown in the Post Deploy tab.

In this case, it is likely that the Remote Bottom modem attached to the OBS is not waiting long enough for the OBS system to process and collate the data payload before the modem send its response.

In this case it is necessary to increase one or more Local Modem Delays (DD, UD, MD or ICT) to force the Bottom modem to give enough time to the OBS to process a request for data.

The correct Local Modem Delay parameter values depend on the data processing operation that the OBS must carry out. They should be set correctly from factory and should not require alteration. If they require alteration, contact Güralp in the first instance.

If it is not possible to contact Güralp, then trial and error should be employed to identify which Local Modem Delay parameter value requires alteration. Increase each delay parameter in turn by single steps as required to regain communication with the OBS.

MDFT response missing subframe:
The MDFT command may be received by the OBS Bottom modem and subsequently by the Surface modem, however the data payload may be lost. This would look like the following in the modem debugging window:

<MDFT:aaaa;W1

>[MOD:TX;15;MST1]

>[MOD:RX;NO_DATA[XC98,SNR15,DBV-11,TEL;TCS1;RPSKV2_100,
FEC0;0;-1;0;0]]

>[MOD:RX;NO_REPLY[XC0,SNR0,DBV0,TEL;NONE]]

>[MOD:STATUS;16,ID;11]

>[MOD:THEIR_ACKS;8000]

>[MOD:DONE]

Here the modems can communicate Commands but struggle to transmit payload data.

Assuming that correct parameters values for power, gain and receiver wait have been set in the previous troubleshooting procedures; it is most likely that the data bitrate is set too high for the deployment scenario. The Telemetry Scheme (TS) parameter should be reduced in single steps until the MDFT Data transmission is reliably successful.

If TS is set to the lowest setting but data transmission is still failing, revisit earlier troubleshooting steps to validate other modem parameters.

15.3.4 Get Seismic Data

The most arduous test of the acoustic link is the transfer of seismic data from OBS to the surface. Seismic data is retrieved as individual 4KiB miniSEED records.

Using one of the methods outlined in this manual, identify and attempt to retrieve a miniSEED record. If successful, the following can be observed in the modem debugging window:

<MDFT:aaaa;W1

>[MOD:TX;15;MST1]

>[MOD:RX;15,FROM;5110[XC98,SNR18,DBV-8,TEL;TCS1;HDR_SE_3500,
FEC0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0],MY_ACKS;8000]

>[MOD:RX;14,FROM;5110[XC97,SNR18,DBV-8,TEL;TCS1;HDR_SE_3500,
FEC0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0],MY_ACKS;C000]

>[MOD:RX;13,FROM;5110[XC98,SNR18,DBV-8,TEL;TCS1;HDR_SE_3500,
FEC0;0;0;0;0;0;0;0;0],MY_ACKS;E000]

>[MOD:STATUS;16,ID;10]

>[MOD:THEIR_ACKS;8000]

>[MOD:DONE]

The number of frames and sub-frames required to transmit 4 KiB depends on the value of the Telemetry Scheme parameter; the higher the TS value, the fewer sub-frames required.

At the end of the Data transmission, the data viewer window should open to display the seismic data.

15.3.4.1.1 Seismic Data Transmission Failure

If the data viewer window fails to open, it is likely that one or more sub-frames were lost leading to an incomplete miniSEED record. This can be confirmed in the modem debugger window with the presence of:

>[MOD:RX;NO_DATA[XC98,SNR15,DBV-11,TEL;TCS1;RPSKV2_100,
FEC0;0;-1;0;0]]

And/or:

>[MOD:RX;NO_REPLY[XC0,SNR0,DBV0,TEL;NONE]]

FEC is the number of telemetry code symbol errors corrected by the forward error correction algorithm. -1 indicates that the correction power has been exceeded, so the error could not be corrected. The number of reported FEC values and the number of correctable errors is dependent on the telemetry type.

FEC values <4 are indicating a reasonable acoustic link, while FEC values between 4 and 6 are indicating a difficult acoustic link.

The number of permitted dropped sub-frames depends on the value of the Modem Retries or MR parameter. The higher the value for MR, the more sub-frames may be dropped with a successful data transfer.

In any case, the procedure for reducing the number of missing sub-frames is the same as the case of short Data transmissions. Revisit the previous section, or prior sections if necessary, to verify correct parameter values. Starting by lowering TS in the bottom modem.