Technical Notes and Papers

Conference Papers and Magazine Articles

  1. "Real Time Deep Water Current Profiling System", IEEE Oceans 2000

  2. "Wireline Quality Underwater Wireless Communication Using High Speed Acoustic Modems", IEEE Oceans 2000


Technical Notes

  1. Working Principles of LinkQuest's Acoustic Modems.

  2. How to Interface LinkQuest's Modems to Your Instrument.

Working Principles of LinkQuest's Acoustic Modems

LinkQuest’s acoustic modems are two-way, half duplex modems which has a link layer communication protocol. They also contain internal buffer for data storage. These acoustic modems provide completely transparent RS-232 interface to any instruments or PC's. Once the modems are powered up they are ready for service.

When no data is being transmitted the modem stays in Sleep Mode whereby it periodically wakes up to monitor possible data being transmitted by the far-end modem.  When the modem is sleeping (i.e. prior to waking up in the sleep mode) the power consumption is very low (i.e. approximately 8 mW).   When no data is being transmitted, the modem will spend the majority of the time sleeping in the Sleep Mode to conserve power.  The percentage of sleep time vs wake-up time in the Sleep Mode is configurable. The more frequently the modem wakes up the quicker it is for the modem to acquire signals from the other modem; however, this increases the power consumption of the modem. In order to explain the rest of the working principles of the modem, we will use the example whereby the bottom modem tries to send data to the surface modem.

While the bottom modem is in the sleep mode, if the bottom modem receives data from its RS-232 link connected to the bottom instrument, the bottom modem will switch to the Transmit Mode immediately and begins to transmit data. As soon as the surface modem wakes up and detects the signal from the bottom modem, the surface modem will switch from the Sleep Mode to the Receive Mode and start to receive data. After the data transmission is complete, both the surface modem and the bottom modem will return to the Sleep Mode until more data is available on the RS-232 line.

Each of the modems comes with 900k bytes of input data buffer.  This is to ensure that data from the RS-232 line do not get lost in the acoustic modem in case the communication channel between the two modems is temporarily degraded significantly.   Once the channel restores to sufficient operating conditions, the buffered data will be transmitted to the surface modem in the order it was received, without any human intervention. 

In many applications, the power consumption of the surface modem is not as critical as the power consumption of the bottom modem. If data are often uploaded from the bottom modem to the surface modem, the surface modem may be configured to wake up frequently to ensure quick receipt of data sent from the bottom modem, while the bottom modem may be configured to wake up much less frequently to conserve power. In applications such as AUV/UUV, both the surface modem and the bottom modem can be configured to wake up all the time to ensure the least delay possible.

[Return to Top]

How to Interface LinkQuest's Modems to Your Instrument

Prior to reading this technical note please be sure to read through the technical note on the "Working Principles of LinkQuest’s Acoustic Modems".

LinkQuest’s modems are designed to be user friendly and provide a completely transparent wireless RS-232 connection between two end equipment as if they are directly connected through an RS-232 cable. LinkQuest’s RS-232 is configured at 9600 baud, 1 start bit, 1 stop bit, 8 data bit, no parity bit and no flow control. You should make sure that the RS-232 configuration of your instrument and any relevant application software are also configured the same as LinkQuest’s RS-232 configuration. This is the configuration most commonly used in many popular Doppler Current Profilers and CTD’s. If you cannot set to this RS-232 configuration, please contact your instrument manufacturer or contact LinkQuest and we may consider modifying the RS-232 configuration to fit your needs for a nominal fee.

LinkQuest’s modems are two-way, half-duplex modems. This means every modem can either send data to the other modem or receive data from the other modem (i.e. two-way), but not at the same time (i.e. half-duplex). If both modems send data to each other at the same time, collision will occur. Although LinkQuest’s modems are equipped with sophisticated collision avoidance algorithm, it does require extra time to conduct handshaking between the two modems involved in the collision (i.e. the extra time to determine which modem sends data first). Whenever possible, collision between two modems should be avoided to optimize the effectiveness of LinkQuest’s modems. In the typical application when one surface modem communicates with the bottom modem, collisions may be minimized if the user waits for the response of his first command prior to sending the next command to the other modem. In applications when a command script can be used, it is highly desirable to send the command script to the modem to avoid collisions. The use of command script increases the effectiveness of the half-duplex communication.

In some application software such as terminal emulators supplied by instrument vendors, the local echo is turned off and the keystroke on the computer screen is actually echoed back by the instrument through the RS-232 link. When the local echo of the computer is turned off the keystroke does not appear on the computer screen instantaneously. The keystroke will only appear on the computer screen once the instrument receives the keystroke character and responds (or echoes) with the same message. With cable link, the latency between the keystroke and the reception of the instrument's echo is very small so that as soon as the user enters a keystroke character the character appears on the computer screen. However, with an acoustic modem link, the latency involved in displaying this keystroke character is much larger, and the user may enter another keystroke character prior to the acknowledgment of the prior keystroke character. In this situation, the echo returning from the instrument from the previous keystroke character collides with the successive input keystrokes sent from the computer to the modem. In other words, the new key strokes sent from the computer to the modem and thus from the modem to the instrument will collide with the previous keystrokes sent back by the instrument. It should be noted that this type of collision only happens when the commands are entered by a human being at the computer terminal. Whenever the commands are sent automatically such as using a command script, this type of collision will not occur.

If the user encounters the above problem where the local echo is off and the instrument's echo is on, the user has a few alternatives. The first alternative is to contact your instrument vendor on how to turn off the echo in the instrument and turn on the local echo in the application software such as terminal emulator. When this is done, collision will not occur. A less desirable alternative is to reconfigure the local echo from OFF to ON so that collisions may be minimized. With this approach, the user will see his keystroke characters twice, once when the keystroke character is entered and another time when the instrument echoes back with the same keystroke character. A better method of preventing this type of collision is to send a command script as opposed to typing characters manually one by one. The command script may consist of a series of commands all sent at one time. Once the instrument receives the commands, the instrument will sort out the commands and respond accordingly. The command script is highly efficient and minimizes the possibility of collisions due to echoes. In the case where the command script cannot be used and the local echo cannot be turned on, the interactive commands typed in by the user will not affect the functionality of the communication. The increased collision will only decrease the efficiency of the communication. Furthermore, this type of collision only applies to the initial setup between the user and the instrument, in the case of file transfer this type of collision does not occur.

As explained in the technical note for the working principles of the modems, it will take an average of half the wake-up period to establish connection between the two modems. This delay in establishing the connection may range from a few seconds to as much as 2 minutes in typical cases. In order to compensate for the latency in the modem’s connection please make sure the application software and instrument’s software have timeouts up to 2 minutes, the maximum waiting period you configured, for waiting for response. In the cases where responses are not required, delay will not be a problem.

In the cases where your instrument application software utilizes X, Y or Z modem protocol to retrieve large quantity of data from the instrument, the timeouts defined in the protocol are usually shorter than one minute. LinkQuest has designed drivers to deal with these protocols. Please contact LinkQuest to see how the driver can be used with your instrument.


[Return to Top]

© LinkQuest, Inc. 1999    Last Updated May 2004

setstats 1