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]
|
