Altus Emulation on
Rock Granite/Basalt
Digitizers
Procedures for
integrating Rock digitizers
into an existing network
Application Note #56
Dennis Pumphrey
November 6, 2008
This application note copyright © Kinemetrics, Inc., 2008. All rights
reserved. Kinemetrics products are covered by U.S. and foreign
patents, issued and pending. Printed in U.S.A.
Kinemetrics, Inc., 222 Vista Avenue, Pasadena, CA 91107. USA
Phone: + 1-626-795-2220 „ Fax: + 1-626-795-0868
E-mail: [email protected]
Website: www.kinemetrics.com
ftp:\\ftp.kinemetrics.com
Kinemetrics SA, Zl Le Trési 6B, 1028 Préverenges, Switzerland
Phone: + 41-21-803-2829 „ Fax: + 41-21-803-2895
E-mail: [email protected]
Application Note 56
1
Altus Emulation on Rock
Granite/Basalt Digitizers
Procedures for integrating Rock
Digitizers into an existing network
Introduction
Altus Emulation is intended to present a similar interface to that seen on a K2. The intent is to allow easier
integration of new Granite and Basalt digitizers into existing networks that are set up to handle K2s without
being forced to make the complete leap to full IP-based networking. The Altus Emulation module allows a
Granite/Basalt to look “enough” like a K2 to work with these networks with little or no changes required.
A Rock digitizer for example supports the K2-style dial-in and dial-out sequence, supports the K2’s block
mode for streaming data, as well as K2 command mode with several K2 commands – so it should work for
existing NMS, Earthworm, or Antelope networks that know how to talk to a K2.
Altus Emulation does not do a 100% “impersonation” of a K2, but that’s not the goal.
Unlike the K2, the Granite/Basalt is not limited to a single connection. You can have multiple connections to
different clients – so at the risk of being silly, you could for example simultaneously:
‐ Use the network to transfer recorded files automatically via the FTP Sender module
‐ Manually connect via the network and “pull” files via secure copy
‐ Connect via the web interface to change parameters or view files
‐ Run an instance of Altus Emulation dialing out and delivering files to NMS by modem
‐ Run a second instance of Altus Emulation streaming data over the network to Earthworm
‐ Run a third instance of Altus Emulation streaming data over the network to a second data center (maybe
at a different sample rate)
‐ Run a fourth instance of Altus Emulation so that you can connect on site to a serial port and give K2style commands
Altus emulation can be done many ways, but this App Note covers what we expect to be the three most
common:
Using a Modem
Via TCP/IP
Via Direct RS-232
Application Note 56
2
Altus Emulation using a modem
This would be for the case where you want to dial into or out of the Granite/Basalt as if it were a K2. For
example, to dial out and connect to the NMS system at NSMP Menlo Park.
Typically you DO NOT stream data over a modem.
To setup this configuration, you must do two things:
First add an Altus Emulation module via TCP/IP, with streaming disabled and modem enabled something
like this:
Application Note 56
3
Note that we have:
o Enabled modem use
o Enabled some reason to call (on event in this case)
o Provided a phone number
o Disabled streaming by setting buffer size to zero
Note also that the TCP/IP port number is set to 9800 (that is the default).
And second, you must configure Rockhound’s TTYMonitor, which makes a logical connection between a
modem and an IP port. See the Rockhound manual for examples.
When you configure TTYMonitor, you must define three things:
Which device will be used:
o /dev/modem1 is the internal modem
o /dev/ttySx is one of the available serial ports, with ‘x’ being a number. “lsoptions” will list available
serial ports for your system. You might use this with an external modem.
The modem init string.
The default init string is good for most modems, but you might need to change it.
The TCP/IP port that TTYMonitor communicates with.
This should match the port specified in the Altus Emulation via TCP/IP module (9800 in this
example)
Please note:
TTYMonitor is ONLY used as an interface between a modem (internal or external) and a TCP/IP port (in
this example, 9800)
TTYMonitor overrides the init string defined in the Altus Emulation module
There is a significant advantage to using the TTYMonitor. If something happens to the application software
(for example) the layout gets corrupted, then the Altus Emulation module will not run. This could mean that
the unit would not be able to answer the modem and a site visit would be required. However, since the
TTYMonitor is a separate program, it will still answer the modem. If the first character seen by TTYMonitor
after connection is a “$”, then TTYMonitor will present you with a Linux login prompt, and you can log into
Linux to fix any problems. If the first character is not a “$”, then TTYMonitor assumes you want to
communicate with the Altus Emulation module at the specified IP port.
Altus Emulation via TCP/IP
This would be for three applications:
‐ To stream data to something like Earthworm using the K2’s serial data stream protocol over a network.
‐ To do event reporting using the network, for example, to communicate with NMS in Event Direct mode
via TCP/IP.
‐ To connect to the instrument via a network and give K2 commands.
The result is something that looks very much like a K2 with a terminal server attached (like a UDS-100 or an
MSS-100), except that you don’t need the terminal server. You connect directly to the Ethernet of the
Granite/Basalt.
Application Note 56
4
In this case, you DO NOT want to use the TTYMonitor software, so to avoid conflicts you should use a
different IP port than that assigned to TTYMonitor. In the examples below, we have changed the port
number to 9801.
To do this, you must add an Altus Emulation through TCP/IP module, configured something like the
following:
For Streaming:
Note that:
‐ Port number has been changed to 9801
‐ Modem functions are disabled
‐ Streaming data is enabled by setting the buffer size.
You could now connect and stream data from port 9801.
Application Note 56
5
For Event Direct event reporting:
Note that:
‐ Port number has been changed to 9801
‐ “Modem” functions are enabled
‐ Dial string is set to ALTUS
‐ Phone number is set to EVENT
‐ Streaming data is disabled by setting buffer size to zero
You could now configure NMS for event reporting from port 9801.
Application Note 56
6
For a Network based command interface:
Note that:
‐ Port number has been changed to 9801
‐ Modem functions are disabled AND THAT
‐ Streaming is disabled by setting the buffer size to zero
You could now connect to the unit at port 9801 with telnet or puttytel and get an Altus “*” prompt.
Application Note 56
7
Altus Emulation via RS-232
This would be for three applications:
‐
‐
‐
To stream data to something like Earthworm using the K2’s serial data stream protocol over a direct RS232 connection.
To do event reporting over RS-232, either by some direct connection (a radio or short haul modem) or
an external modem connected to a Granite/Basalt RS-232 port.
To connect to the instrument via an RS-232 port and give K2 commands.
The Altus Emulation via RS-232 module should ONLY be used if it is the secondary connection, meaning
that there is some other way to communicate with the instrument (a network or other modem connection
that uses the TTYMonitor). Or if the Granite/Basalt is completely standalone and you just need to be able to
give K2-like commands via an RS-232 port. Note in all of the examples below that you MUST select this as
a secondary connection (not your primary interface to the system) or it will not work. This is to force you to
stop and think about it. We expect that in most cases, you really should be using the Altus Emulation via
TCP/IP module and the TTYMonitor (for the reasons described above), but there MAY be cases where
direct use of Altus Emulation via RS-232 as a secondary connection is appropriate.
Application Note 56
8
For Streaming via RS-232:
Note that:
‐ COM port has been assigned (/dev/ttyS5 in this example)
‐ Baud rate has been set
‐ Connection has been defined as a “secondary” port. Without this selection, the connection WILL NOT
WORK, forcing you to reconsider whether this is what you really want (and in most cases it is not)
‐ Modem functions are disabled
‐ Streaming data is enabled by setting the buffer size
You could now connect and stream data from /dev/ttyS5.
Application Note 56
9
For Event Direct reporting via RS-232:
Note that:
‐ COM port has been assigned (/dev/ttyS5 in this example)
‐ Baud rate has been set
‐ Connection has been defined as a “secondary” port. Without this selection, the connection WILL NOT
WORK, forcing you to reconsider whether this is what you really want (and in most cases it is not)
‐ “Modem” functions are enabled
‐ Dial string is set to ALTUS
‐ Phone number is set to EVENT
‐ Streaming data is disabled by setting buffer size to zero
You could now configure NMS for event reporting from a serial port connected to /dev/ttyS5.
Application Note 56
10
For a Command Interface via RS-232:
Note that:
‐ COM port has been assigned (/dev/ttyS5 in this example)
‐ Baud rate has been set
‐ Connection has been defined as a “secondary” port. Without this selection, the connection WILL NOT
WORK, forcing you to reconsider whether this is what you really want (and in most cases it is not)
‐ Modem functions are disabled AND THAT
‐ Streaming is disabled by setting the buffer size to zero
You could now connect to the unit at /dev/ttyS5 with HyperTerminal, puttytel or other terminal software and
get an Altus “*” prompt.
Application Note 56
11
References
Some useful documents for operating your Rock Digitizer are:
304702 Rockhound manual
300715 Rock Granite/Basalt Digitizer manual
Most manuals can be found at www.kmi.com, downloads Æ manuals.
300654-PL Rock Software Support CD
Digitizer Support Software can be found at www.kmi.com, downloads Æ Rock Platform Æ Digitizers