GS Technical Manual

Geophysical Seismometer
Technical Manual
Gareth Goldswain
ISS International Limited
January 2010
1
Geophysical Seismometer Technical Manual 2
Contents
1 Introduction 6
2 Hardware Overview 6
2.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Mainboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Slow485 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5 Dataash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Digitizer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 RS232 modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2 FSK modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 RS485 modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Sensor Identication module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 External Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 GS Cable Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Firmware Overview 10
3.1 Bootloaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 I-boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 U-boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Operating system and services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Remote login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Web server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Network time protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Ramdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 GS specic rmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1 /root/gs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.2 /root/gs/code/cpu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.3 /root/gs/code/pld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.4 /root/gs/code/utls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 GS startup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Communication 17
4.1 Command Message Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Communication Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Copyrights ISS International Limited
4.3 Basic parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Communication sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1 Boot sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 IPL sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Trigger sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.4 Failure sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.5 Uninitiated CMP messages . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.6 Ad-hoc CMP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 Standalone operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.6 Conguration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6.1 Conguration parameter priority . . . . . . . . . . . . . . . . . . . . . . . 24
4.6.2 System data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 External Devices 26
5.1 Intelligent UPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.1 iUPS Modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1.2 iUPS connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 External Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Glossary and Abbreviations
ATU Analogue Time Update.
Bootloader The initial set of operations that the computer performs when power is switched
on. The bootloader typically loads the main operating system for the computer.
Box ISS Seismometer.
Broadband Sensor A sensor capable of measuring a wide range of signal frequencies.
CC Central Computer.
Client An application or system that accesses a remote service on another computer system.
CMP Command Message Protocol.
Comms Communications.
Daemon A computer program that runs in the background, rather than under the direct control
of a user.
Dataash A low pin-count serial interface for ash memory.
DMA Direct Memory Access.
Downlink Communications link from central computer to device.
DTU Digital Time Update.
Ethernet Family of frame-based computer networking technologies for local area networks.
Flash Flash Memory.
Flash Memory A non-volatile computer storage that can be electrically erased and repro-
grammed.
FPGA Field Programmable Gate Array.
FSK Frequency Shift Keying.
Gateway A node on a TCP/IP Network that serves as an access point to another network.
Geophone A device which converts ground movement (displacement) into voltage.
GPRS General Packet Radio Service; a packet oriented mobile data service available to users
of the 2G cellular communication systems global system for mobile communications (GSM), as
well as in the 3G systems.
GPS Global positioning system.
GS Geophysical Seismometer.
Hostname A label that is assigned to a device connected to a computer network.
HSDPA High-Speed Downlink Packet Access (HSDPA) is an enhanced 3G (third generation)
mobile telephony communications protocol in the High-Speed Packet Access (HSPA) family.
i-boot ISSIs proprietry rst tier bootloader.
IPC Inter Process Communication.
ISS Integrated Seismic System
ISSI Integrated Seismic System International.
Linux A generic term referring to Unix-like computer operating systems based on the Linux
kernel.
MAC Address A unique identier assigned to most network adapters or network interface
cards.
Nameserver A computer consisting of a program or computer server that implements a name-
service protocol. It maps a human-recognizable identier to a system-internal, often numeric,
identication or addressing component.
NTP Network Time Protocol.
NTPD Network Time Protocol Daemon.
Operating System An interface between hardware and user which is responsible for the man-
agement and coordination of activities and the sharing of the resources of a computer, that acts
as a host for computing applications run on the machine.
Piezoelectric Sensor A device that uses the piezoelectric eect to measure pressure, acceler-
ation, strain or force by converting them to an electrical signal.
PPS Pulse Per Second.
RAM Random Access Memory.
Ramdisk A block of RAM that a computers software is treating as if the memory were a disk
drive.
resolv.conf The name of the conguration le for the BIND Domain Name System (DNS)
resolver library used on UNIX-type systems to resolve hostnames.
RS232 Recommended Standard 232; a standard for serial binary data signals connecting be-
tween Data Terminal Equipment and a Data Circuit-terminating Equipment.
RS485 A standard dening the electrical characteristics of drivers and receivers for use in
balanced digital multipoint systems.
RTS Run Time System.
Server A computer system that provides essential services across a network, to private users
inside a large organization or to public users in the internet.
SSH Secure Shell.
TFTP Trivial File Transfer Protocol.
u-boot A boot loader for a number of dierent computer architectures.
UNIX A computer operating system.
Uplink Communications link from device to central computer.
USB Universal Serial Bus.
Web Server A computer program that delivers (serves) content, such as a web page, using the
Hypertext Transfer Protocol.
WiFi A class of wireless local area network (WLAN) devices based on the IEEE 802.11 stan-
dards.
1 Introduction
The GS is the fth generation of digital seismometer forming part of the Integrated Seismic
System (ISS).
The GS is designed to be used in one of two modes, network mode or standalone mode
1
. In
network mode, a connection to the Central Computer (CC) running the ISS Run Time System
(RTS) should be permanently available. The purpose of the CC/RTS is to provide timing and
conguration parameters to, as well as collect data from remote seismometers. Data is buered
internally on the GS and transferred to the central computer upon request. In standalone mode,
the GS obtains timing information via GPS and conguration parameters from internal ash
memory, thus obviating the need for a controlling computer. Data is recorded to external storage
via the USB port by default in standalone mode, and by conguration in network mode.
2 Hardware Overview
The GS hardware consists of a main board (G_CPU board) as well as three modules - a digitizer,
a modem and a sensor identication module. All modules are interconnected via the mainboard,
and interface to the outside world through connectors mounted on the backplate.
2.1 Block Diagram
1
This is dierent to the QS which came in two distinct and divorced variants.
2.2 Mainboard
This board is analogous to the motherboard of a PC, it contains the CPU and all other peripheral
components required to provide the full functionality of the GS. Included on this board is RAM,
ash memory, Ethernet controller, USB controller, serial ports and an FPGA.
2.2.1 Ethernet
The mainboard incorporates an Ethernet interface which is capable of 10 and 100 Mbits opera-
tion, in full- or half-duplex mode.
2.2.2 USB
A USB port is provided for connection to external storage devices. The port is compliant with
the USB V2.0 Full-speed and Low-speed Specication.
2.2.3 Slow485
ISSIs adopted protocol for communication with external devices is dubbed slow 485, which
is based on the RS485 standard. It operates in a bus topology, and is provided along with
DC power on one of the external connectors for connection to satellite devices. The slow 485
protocol is developed and maintained by ISSI, but is an open standard and available to users
wishing to interface with external devices.
2.2.4 FPGA
An FPGA is provided for clocking the digitizer module while ltering and timestamping digital
data captured from it, and streaming this to RAM using DMA.
2.2.5 Dataash
Onboard dataash is provided for storing the GSs rmware and conguration parameters - a
description of the various partitions and their use is detailed further in section 3.4.
2.3 Digitizer module
A variety of digitizer modules are available for the GS, depending on the sensor interface re-
quired
2
. All digitizer modules are 24-bit devices sampled at 48kHz. Lower sampling rates are
achieved using downsampling techniques.
2.4 Modem module
Various modem modules are available for the GS, depending on the application and communi-
cations requirements.
2
Geophone, broadband, force balance or piezoelectric sensors are supported at time of writing.
2.4.1 RS232 modem module
This is the standard modem used for standalone applications as it includes an onboard GPS
module necessary for timing requirements. The RS232 standard is a communications protocol
widely used by hardware manufacturers, allowing for a smooth interface between the GS and
most third party hardware.
2.4.2 FSK modem module
This modem is included in the GS range for compatibility with existing FSK seismic networks.
FSK modulation uses analogue tones to transmit digital data, which allows for long line lengths
3
in wider networks.
2.4.3 RS485 modem module
Unlike the RS232 and FSK communication protocols, the RS485 protocol transfers data between
network nodes via a half duplex bus. Owing to the bus topology of the standard, the RS485
modem module supports two downlink connections (left link/right link) which may be used
to extend the bus. Each module thus acts as a repeater, relaying data between nodes of the
network.
2.5 Sensor Identication module
ISSIs new generation of Smart Sensors are capable of reporting information such as manufactur-
ing data, e.g. sensor type and serial number, and installation data, e.g. sensor orientation. The
sensor identication module provides an interface between CPU and sensor, providing power to
the sensor electronics and implementing the Smart Sensor communications protocol. The GS is
thus able to gather information about connected sensors and relay it to the CC.
ISS Smart Sensors are hot-pluggable devices, and require no conguration or setup parameters
at GS or RTS level.
2.6 External Connections
The GS has ten external connectors, the function and position of each is detailed below:
3
Up to 7km.
Connector Name Function
1 Seismic 1
3 seismic sensor channels,
smart sensor
communication
2 BNC GPS Antenna External GPS antenna
3 Ethernet
Supports up to 100Mb/sec
full-duplex Ethernet.
Communication option.
4 External Slow 485
Satellite device
communication and power
5 USB External storage
6 Comms Downlink
(L)
RS485 communication bus
downlink
7 DC Power
DC power input and
intelligent UPS
communication
4
.
8 Comms Downlink
(R)
RS485 communication bus
downlink
9 Comms Uplink
Communications with
central computer
(RS232/485, FSK)
10 Seismic 2
3 seismic sensor channels,
smart sensor
communication
2.7 GS Cable Wiring
The wiring side of the connectors which mate with the GS chassis are detailed in the following
diagram:
3 Firmware Overview
Each GS is pre-loaded at the factory with a serial number, bootloaders, an embedded version
of the Linux operating system (OS) and all the latest ISS seismometer rmware. The OS and
constituent software package versions are tightly controlled by ISSI, and have been tailored to
meet the specic needs of a digital seismometer.
3.1 Bootloaders
Upon power-up or system reboot, a series of bootloaders are run to bootstrap the GS into a
state which is appropriate for a more sophisticated operating system to take control. These
bootloaders perform extremely low-level tasks such as conguring and initializing the hardware,
and are of little interest to the end user. They are discussed briey below for completeness.
3.1.1 I-boot
An ISSI proprietary Initial Bootloader (i-boot) is used to initiate system memory and dataash.
Functionality is minimal and hands over control to the next level bootloader after approximately
5 seconds.
3.1.2 U-boot
An open source Universal Bootloader (u-boot) provides extended functionality, providing
services such as tftpboot and writing to dataash. The u-boot project page is located at
http://sourceforge.net/projects/u-boot where source code and documentation is available.
After about 5 seconds, u-boot uncompresses the OS kernel and ramdisk images stored in
dataash and hands over control to the Linux kernel.
3.2 Operating system and services
The GS uses a customised version of the Linux kernel as its operating system (ARM Linux -
kernel 2.6.20 at time of writing). Most of the fundamental functionality of the mainstream Linux
kernel is present, but anything not specically required has been stripped.
The OS together with its associated ramdisk (i.e. lesystem) are stored as read-only, compressed
images in on-board ash memory. These images are uncompressed and reloaded in their original
form each time the GS is rebooted. For this reason any les written to RAM will be lost upon
(soft or hard) reboot.
Most of the basic utilities and services of UNIX-type systems (e.g. le copying, external storage
mounting, networking services, etc.) are supplied in the form of a multi-call binary dubbed
BusyBox
5
. Some of the more useful services are discussed in the following sections.
3.2.1 Networking
Each GS, unless specically requested otherwise, is shipped with the default, static network
settings of the following table:
IP address 192.168.1.1
Netmask 255.255.255.0
Gateway 192.168.1.2
The GS is able to use dierent network settings to these defaults, including obtaining dynamic
network settings from a DHCP server using an onboard DHCP client (udhcpc) to implement
the Dynamic Host Conguration Protocol (see http://udhcp.busybox.net for udhcpc documen-
tation).
To change the network settings of the GS, point your browser URL bar to the GSs current IP
address and wait for the GS web interface to load. Click on the "Network and RTS Settings"
button in the control panel (left of screen), populate the network-related elds, and click "Apply".
5
The version of BusyBox supplied with the GS is version 1.2.2. See http://www.busybox.net for details and
documentation.
3.2.2 Remote login
The OpenSSH suite is included in the GS OS, which supports the ssh, scp and sftp protocols.
The suite contains a client and daemon to originate and accept remote logins and transfers. By
default the OpenSSH daemon (sshd) is started at boot time to accept any incoming requests.
See http://www.openssh.com for documentation of the OpenSSH suite.
Note that only one pre-congured user is dened on the GS. For the username and password used
for SSH authentication purposes, or to congure a GS for automatic, passwordless authentication
using public-private key encryption, please contact the ISS support center.
3.2.3 Web server
The GS is able to serve web pages via an onboard web server. By pointing a browser to the
GSs IP address (see section 3.2.1), the GSs web interface can be viewed. The GS web interface
provides the user with a number of monitoring and basic control functions.
3.2.4 Network time protocol
The Network Time Protocol (NTP) is designed to synchronize computer clocks. The protocol
allows for synchronisation of a computer clock to a GPS time source. The NTP daemon (ntpd)
is provided with the GS and is useful in standalone applications where the GS needs to indepen-
dently synchronize its time to GPS time. Refer to http://www.ntp.org/ for further information
on NTP.
Note on operating system and services
Although the above mentioned Linux OS and plethora of system services exists on the GS, they
are transparent to normal seismometer operation and mostly of little interest to the end user.
While useful as debugging and troubleshooting tools, no understanding is necessary for eective
GS deployment or use.
3.3 Ramdisk
The ramdisk is a collection of les (including executables) organized in a tree structure in the
usual manner that one would expect to nd on a conventional PCs hard disk, the dierence
being that ramdisk les are, as the name suggests, held by a lesystem which resides in RAM.
This means that unlike the modications made to les on a PC hard disk, changes made to
les of the ramdisk are lost with power, unless the changes are saved to ash and copied over
the original le which will always be loaded from the same read-only image at boot time
6
. The
methods used to retain changes to ramdisk les are discussed in sections 10 and 4.6.2 of this
document.
The ramdisk contains all the usual UNIX directories (/etc, /usr, /root etc.) and a couple GS
specic directories. It is implicitly mounted by Linux at / as the root lesystem before anything
else.
6
The ramdisk image is loaded by the u-boot bootloader (section 3.1.2) at boot time.
3.4 Flash
There are two banks of dataash on the GS mainboard which are divided into a number of
partitions. Each partition is intended for storage of specic data, detailed in table 1.
Table 1: Flash partition table.
Flash bank Name Data Size
Linux mount
point (le
system)
0 i-boot bootloader 17k n/a
0 u-boot bootloader 293k n/a
0 lesys ramdisk 7.5M n/a
1 code GS code 1M /mnt/code (js2)
1 js2 general 1M
/mnt/jffs2
(js2)
1 kernel Linux 2M n/a
1 data sgram backup, congs 4M /mnt/data (js2)
3.5 GS specic rmware
The GS specic directory structure as dened in ramdisk at time of writing is tabulated in table
2.
Table 2: GS specic directories in ramdisk.
Directory Files/purpose
/root/gs fos for IPC, _v0 les, working directory
/root/gs/code all GS code sub-directories
/root/gs/code/cpu main GS application code (GS_master)
/root/gs/code/pld FPGA code
/root/gs/code/utls GS utilities
Although all GS rmware is packaged with the original ramdisk (in the directory /root/gs/code),
newer code will inevitably be available from CC, which will ultimately be stored in the code ash
partition (table 1). The directory structure of this mounted partition (i.e. below /mnt/code),
exactly matches that below the /root/gs/code directory in RAM (table 2). By performing a
simple copy during the boot sequence, (cp -af /mnt/code /root/gs), all GS code in ash is
copied over the ramdisk versions in RAM. The original code in the ramdisk thus serves as a kind
of redundant backup, i.e. should the code ash partition become corrupted, the original code
packaged in the ramdisk can still be executed.
3.5.1 /root/gs
A few les constitute the minimum rmware requirements for a GS to automatically bootstrap
itself to life by downloading code from CC. These les appear in the /root/gs directory in
ramdisk and are considered stable and trusted. They are never overwritten with newer versions
in ash and have the sux _v0 to indicate that they are version zero les. Table 3 describes
these les.
Table 3: Files in the /root/gs directory (essential and _v0 les).
_v0 le Purpose
getser_v0 standalone executable to fetch the GSs serial
number
calc_checksum_v0.arm standalone executable to calculate the checksum
of the basic parameters
chk_checksum_v0 standalone executable used to verify the
checksum of the basic parameters
run_gs_v0 daemon script responsible for keeping the main
GS code running
GS_master_v0.gz gzipped version of the main GS code
gs_helper_v0.sh script used for IPC
gs_fifo.cmd fo special le used for IPC
gs_fifo.rsp fo special le used for IPC
The /root/gs directory also serves as the general working directory for all GS specic tasks. All
seismogram and other temporary les created by the main GS application code appear beneath
this directory.
3.5.2 /root/gs/code/cpu
The main GS code sits in this directory and is named GS_master.gz. It is unzipped into the
working directory (/root/gs) at run time from where it is executed. This code is responsible
for running all trigger algorithms, communicating with CC and is essentially the heart of the
GS.
3.5.3 /root/gs/code/pld
A gzipped version of the binary FPGA code, needed to clock the digitizer among other things, re-
sides here. This le is named according to the convention: pld<A2D_ID>_<SRATE1>_<SRATE2>v<VERSION>.bin.gz
where SRATE1/2 are the sample rates of seismic 1 and 2 (in kHz) respectively e.g. pld055_3_3v1.bin.gz.
This naming convention is used, because it is the FPGA which determines the sample rate on
each seismic input. Also contained in this directory is the default FPGA code contained in the
original ramdisk image (pld.bin.gz), and a link to the relevant FPGA code (pld.bin.gz.ln).
3.5.4 /root/gs/code/utls
General utilities used by the main GS application code and are stored in this directory. Scripts
to program the FPGA, send messages on the slow 485 bus, check the sampling rate, fetch the
serial number etc. appear here. Many of these les are useful debugging tools. The following
table describes these les.
Table 4: Files in the /root/gs/code/utls directory (GS utili-
ties).
.gs_utls_info a text le which holds information about the tarball which
the current utility les were extracted from
.gsrc a text le which contains the default environment variables
used to control some of the runtime parameters of the
GS_master code
calc_checksum.arm calculates the checksum of a given le <FILENAME>, and
writes the binary checksum value to a le named
<FILENAME>.chk; useful when changing values in the box
conguration le, which then needs to have its checksum
re-calculated for the run_gs daemons validation purposes
chk_checksum validates the checksum of a given le <FILENAME> against
the binary value found in a le named <FILENAME>.chk if
it exists
deccnt decrement the ASCII count value in a le
etc a directory used for conguration settings; obsolete in GSs
manufactured after May 2008
getcnt get the ASCII count value in a le
getsensdata fetches the sensor identication information stored on the
sensor ID daughter board
getser fetches the GSs serial number stored on the sensor ID
daughter board
gpsdate sets the system time as obtained from the GPS module
gpsstat displays GPS statistics such as the number of satellites
being tracked, x quality and position coordinates
gpstime displays the time as obtained from the GPS module
without setting the system time
gpsutl multicall executable for gpsdate, gpstime and gpsstat
gs_helper.sh a script which runs bash commands written to the named
pipe /root/gs/gs_fifo.cmd and writes the return code to
the named pipe /root/gs/gs_fifo.rsp
gs_portal.sh a daemon script (which is started by the GS_master code if
so congured) which persistently copies seismograms
logged to disk and health data to a remote server using the
SSH protocol
gsipconf.sh an interactive script used to congure the GSs networking
parameters
inccnt increment the ASCII count value in a le
is4c.ko digitizer modules device driver
pldbb.ko FPGAs bit banging device driver
pldconf executable used to bit-bang the FPGA
pldconf.sh script used to program the FPGA, removing and inserting
the appropriate device drivers in sequence
pldloaded determines whether the FPGA is programmed and if so,
with what version and what sample rate it realizes
run_gs daemon script responsible for ensuring that the GS_master
code is kept continuously alive with all necessary
conguration and executable les in place
s485 multicall executable used by s485ping and s485send
s485ping sends a PING message to any known slow 485 device
s485send sends any known message to any known slow 485 device
testups sends a series of slow 485 commands to the UPS and
displays the response - helpful for checking the UPSs
health
3.6 GS startup procedure
Once the OS has started all essential services, a hardware probe is performed to determine the
boxs serial number
7
. If a valid serial number is found, the run_gs daemon script is automatically
started. A ow chart documenting the logic of the GS run script appears in gure 1. Without
a valid serial number the box has no identity and cannot attempt to communicate with a CC;
the run_gs daemon script will not be started.
7
Each GS has a unique serial number embedded into internal EEPROM at the factory during production.
Figure 1: Flow chart of the GS run script.
4 Communication
When running in an RTS supervised seismic network, the GS is completely congured and con-
trolled by the RTS using the command message protocol (CMP), over a digital communications
link. In standalone mode, where the GS acts autonomously, a communications link between
GS and CC is also necessary for conguration and setup purposes. The communications link
between GS and CC is therefore a vital part of the ISS and essential for GS operation. In
fact, in RTS supervised mode, the communications link is always the bottleneck as far as data
throughput is concerned, which is why it is of the utmost importance to always use the highest
quality and fastest communications link possible.
4.1 Command Message Protocol
At the time of writing, all communications between CC and GS are exchanged using the ISS
Command Message Protocol (CMP). Briey, CMP messages are structured as in table 5:
Table 5: CMP message structure.
Byte
position
1 2 3 ... N-1 N
Byte value
Command
ID
Box ID
1st data
byte
...
Last
data
byte
Checksum
Description
Unique
ID of
CMP
message
Unique
ID of
station
CMP
message
specic
data
...
CMP
message
specic
data
Error
checking
Usually, messages from CC to box are referred to as messages, and those from box to CC as
acknowledges (acks).
4.2 Communication Options
The GS is available with a number of dierent digital communications options. Besides the
protocols realised by the internal modem modules of section 2.4 (i.e. RS232, FSK ans RS485).
The GS is also geared for UDP and TCP/IP over Ethernet. This means that any external digital
communications equipment (e.g. WiFi, HSDPA, DSL modem, etc.) with an Ethernet interface
is suitable for GS communications.
Note on Ethernet Communication
Because the delivery time of network data packets is not guaranteed between network devices
(e.g. switches, hubs, routers), there is no reliable and suciently accurate
8
means of time syn-
chronisation via the GS Ethernet port. Instead each GS must achieve time synchronisation either
via GPS, available on the internal RS232 module, or via the RS232 modules serial port interface
using the standard ATU mechanism. Either way, any GS intended for Ethernet communications
must be equipped with an internal RS232 modem module.
xDSL
ISS branded external Digital Subscriber Line (DSL), modems specically designed to pass the
ATU signal (regular DSL modems block it) are available from ISSI, and are particularly useful
in underground applications where timing cannot be obtained via GPS.
8
An accuracy of sub 10sec is necessary for microseismic arrays, which is unattainable using even NTP (section
3.2.4).
4.3 Basic parameters
All GSs are shipped precongured for their intended application. The communications parame-
ters should be altered with care, if at all necessary, and preferably by an ISS technician.
For all communication options save Ethernet, the GSs communication conguration parameters
are stored in the boxs unique conguration le created using the boxcon or jconfig programs
on the RTS host computer. This le, known as the boxle, holds all essential parameters needed
by the GS to congure its serial communication hardware, as well as its network-unique box ID.
These parameters are collectively referred to as the boxs basic parameters.
For Ethernet communication, the GS will always try communicate with the IP address it resolves
for the hostname centralsite. How the GS resolves this name and obtains its own IP address
is dependent on the network conguration chosen. Section 3.2.1 stated that the recommended
way of conguring a GSs Ethernet/networking parameters such as IP address allocation was
via the DHCP method. Should a static IP conguration be required however, this needs to be
congured by remote login or via the browser interface. A number of les need to be written
to ash to ensure that upon next reboot, the network interface is brought up with the desired
settings. A script entitled gsipconf.sh included in the utls tarball (section ??) of the GS is
a useful interactive tool for creating these les in the correct format and saving them to the
correct location.
4.4 Communication sequences
Most of the possible message sequences between CC and GS at time of writing are broadly
described below.
4.4.1 Boot sequences
The boot sequence is only used until the GS has valid basic parameters and code
9
. Essentially,
each time the GS boots and nds a valid serial number (as described in section 3.6), it checks
its basic parameters and code for validity and then either initiates the BOOT sequence or the
NORMAL startup sequence.
The decisions governing which sequence is initiated are made by the run_gs daemon detailed in
gure 1, and elaborated upon below:
Basic parameters boot sequence
If the GS has no valid basic parameters, the run_gs script will start the GS_master(_v0) code
with the -b argument:
GS sends a QS_BOOT
10
message, using default basic parameters (see table 6).
CC returns a QS_BOOT message with the basic parameters as congured in the boxle
on the RTS computer with corresponding serial number.
The GS_master(_v0) code exits after saving the basic parameters to ash.
9
Unlike earlier generation ISS digital seismometers, the GS requires 3 separate lots of code - cpu code, pld
code and utilities code. See section 3.5.
10
QS in the name of this message is merely due to legacy reasons, as the GS re-uses mostly the same messages
as its predecessor (the QS).
Code request boot sequence
If the GS has valid basic parameters but no valid code, the run_gs script will invoke the
GS_master(_v0) code with either the -cc (cpu code), -cu (utls code) or -cp (pld code) ar-
gument:
GS sends a QS_BOOT message using basic parameters loaded from ash, and the appro-
priate code type ag set
CC sends CODE (block 1)
GS acknowledges
CC sends CODE (block 2)
GS acknowledges
...
CC sends CODE (block n) with last block ag and checksum
If the checksum is valid, GS_master(_v0) burns the downloaded code to ash and exits
Table 6: GS default basic parameters.
Parameter Default value
baud rate 115200
parity none
databits 8
hardware handshaking none
stopbits 1
box ID 0
polling disabled
4.4.2 IPL sequence
Once a GS has valid basic parameters and code, it begins negotiating the IPL (Initial Parameter
Load) sequence with CC:
GS sends RESET
CC returns:
SET_POLL
SET_DATETIME
QUERY_BOX
UNIAXIAL
A2DPARMS
SUB_SENSITIVITY (per site)
SET_SCRAM (per site)
SET_STATE (per site)
END_EVENT (per site)
GMP_SETUP (per site)
STP_SETUP (per site)
BOXPARMS1
STAT_UNIAXIAL
POWER
QS_SETUP
each of these messages is acknowledged by the GS and the CC uses this to trigger the next
message. See table 7 for a brief description of these messages. The parameters transferred
through the IPL sequence are loosely referred to as seismic parameters, and the last message in
the IPL sequence (QS_SETUP), triggers the GS to save these to ash.
Table 7: IPL messages
IPL message Purpose
SET_POLL Set boxs polling parameters
SET_DATETIME Update boxs digital time (DTU)
QUERY_BOX Query boxs serial number, A2D module type
and sampling rate
UNIAXIAL Congure boxs sensor conguration
A2DPARMS Set boxs sample rate (may initiate pld code
download sequence)
SUB_SENSITIVITY Congure the boxs trigger parameters (e.g.
trigger level, STA length, LTA length)
SET_SCRAM Set the boxs SCRAM parameters
SET_STATE Set the boxs adaptive decimation parameters
and congure triggered/continuous operation
END_EVENT Set the boxs de-trigger level, and min/max
seismogram length attributes
GMP_SETUP Congure the GMP logical channels report
period
STP_SETUP Congure the STP logical channels parameters
(e.g. trigger level, min event length)
BOXPARMS1 Set the maximum size of seismograms that are
allowed to be sent in, and the maximum
number of seismogram buers
STAT_UNIAXIAL Request the version of boxs rmware and pld
code versions
POWER Request the boxs power information
QS_SETUP Set the boxs seismic network parameters (e.g.
site IDs, net ID) and logging parameters
4.4.3 Trigger sequence
When a GS triggers, the trigger information is communicated to CC to enable the RTS to
perform event association ac cross its entire seismic network. If a trigger forms part of an event
it will be requested by CC:
GS sends TRIGGER_DATA
and when ready to transmit the buer (i.e. seismogram has de-triggered, adaptive decimation
is complete),
GS sends RESULTS_DATA
CC acknowledges RESULTS_DATA
and if CC associates the trigger with an event,
CC sends LOCKB_BUFFER
GS acknowledges LOCKB_BUFFER
CC sends SEND_BLOCK (block 1)
GS acknowledges
CC sends SEND_BLOCK (block 2)
GS acknowledges
...
CC sends SEND_BLOCK (block n)
GS acknowledges with last block ag set (end of trigger)
CC sends CLEARB_BUFFER
GS acknowledges CLEARB_BUFFER
If however the trigger does not form part of an event, CC skips the LOCK_BUFFER, SEND
BLOCK sequence sending the CLEAR_BUFFER instead.
4.4.4 Failure sequences
The RTS places a timeout on most messages sent to a box and waits for an acknowledge. If
the acknowledge is not received before the timeout expires, the message is resent. After a
few unsuccessful attempts, the CC will indicate the station as inactive and will try to RESET
the station. The station has timeouts on RESET and RESULTS DATA and will continue to
send these messages until communications is established. The station has a graceful return to
RESULTS DATA if communication is lost while transmitting a seismogram, giving as much
opportunity for recovery as possible.
4.4.5 Uninitiated CMP messages
A number of messages are sent by the GS not directly responding to messages received from
CC, i.e. as a result of some external or environmental factors. These messages are tabulated in
table 8. Note that in polling mode, with the exception of the QS_BOOT and RESET messages,
a GS will only ever transmit messages when it receives the next POLL_BOX from CC.
Table 8: Messages sent by GS not directly initiated by CC.
Uninitiated message from box Purpose
TRIGGER_TIME Report time of trigger
RESULTS_DATA Acknowledgment of seismogram buer ready to
send
GMP_RESULTS Sending of GMP data
STP_RESULTS Sending of STP data
CLEARB_BUFFER GS made decision to clear a seismogram buer
and has cleared it
ATU Acknowledgment of receipt of the analogue
time update signal
RESET GS is requesting to be initialized
QS_BOOT GS is requesting code or basic parameters
4.4.6 Ad-hoc CMP messages
The CC uses a number of messages initiated on a ad-hoc basis (including operator requests) to
send data to, or request data from the GS. Table 9 details these messages.
Table 9: Ad-hoc messages sent by CC.
Uninitiated message from box Purpose
STATUS Request station status
SET_DATETIME Updates digital time of box (DTU)
SUB_SENSITIVITY Sets trigger level of GS
FORCE_TRIGGER Request station to apply a test pulse to its
sensor inputs
QS_CODE Download code to the box
QS_BOOT Send basic parameters to GS
4.5 Standalone operation
The GS is capable of running in standalone mode, meaning that it will operate autonomously,
synchronizing its clock to GPS time (section 4.7) and logging seismograms to local storage for
oine processing. Whether the data are retrieved on site by physically removing storage media,
or remotely using remote access techniques is purely application de pendant. The minimum
hardware requirements for standalone operation are thus twofold; rstly the GS should be tted
with an ISSI RS232/GPS modem module, and secondly, the GS should have a writable storage
medium connected via its USB port (see section 5.2). If either of these requirements are not
met while the GS has its standalone conguration ag set, the GS will revert to the RESET
state waiting for the IPL sequence.
If, at startup, valid conguration parameters are found with the standalone ag set, and the
above requirements are met, the GS will not wait for IPL but proceed with initialisation and
start the usual seismometer tasks. Should either of these requirements fail while the standalone
ag is set, the GS will revert to the RESET state and wait for the IPL sequence.
Once running in standalone mode, the GS will still receive and act upon any messages sent by
CC, allowing it to be recongured while in standalone mode. Note however that changing a GS
between standalone and normal networked mode required a reset for the changes to take eect.
4.6 Conguration parameters
The run time parameters of the GS are congured on the RTS machine. These parameters
are transferred to the GS either during the IPL sequence (section 4.4.2) or as required. All
parameters obtained through the IPL sequence are stored in ash memory and are reloaded
upon next startup. If the parameters loaded from ash memory at startup are valid and do
not stipulate standalone operation (section 4.5), then the GS will wait for the IPL sequence to
complete with a timeout of 5 minutes. If this timeout expires before the IPL sequence completes,
the GS will proceed using the loaded conguration and start the usual seismometer tasks. This
way a properly congured GS which has been reset while unable to contact CC will not wait
indenitely for IPL, but gracefully continue normal seismometer operation until communications
are re-established.
4.6.1 Conguration parameter priority
A number of ash partitions, detailed in table 1, are available for data storage on the GS. Any
data which needs to survive a reboot needs to be stored in one of the mounted ash partitions
(i.e. js2, code, data). Upon reboot, the OS initialisation scripts copy parameters from these
partitions to the appropriate locations in ramdisk. Where the data resides in ash and the
order in which the initialisation scripts copy the data from ash is thus important - these details
appear in table 10.
Table 10: Flash conguration data priority.
Flash partition Priority Purpose
js2 lowest general purpose storage
code ... code and semi-static conguration parameters
data highest box-specic conguration parameters
Note that all run time parameters sent to the GS during the IPL sequence are stored in the
highest priority ash partition by default. In most situations, the end user neednt worry about
where conguration parameters are being stored internally on the GS, as the GS_master code
uses suitable defaults. Only when highly customised GSs are congured (e.g. static network
conguration, specialised boot scripts and cron jobs), does conguration parameter priority need
to be considered.
4.6.2 System data storage
This document has emphasized the fact that any permanent changes to the ramdisk need to be
stored in ash memory. The de-facto location for this storage is in the data partition (table
10) as it has the highest priority (i.e. any box-specic data will be retained) and is the largest
available partition mounted within Linux.
Because it is impossible to anticipate all possible directories in which data dierent from that of
the virgin ramdisk may be required
11
, a directory /mnt/data/config/sys is tested during the
Linux initialisation scripts, and if it exists, its contents are copied recursively to the / directory
in ramdisk. Thus, any les/directories which appear below this directory in ash will appear
in ramdisk with the leading /mnt/data/config/sys removed from their path. Any les which
exist both in the virgin ramdisk and in ash will thus be overwritten, and any les which do not
exist in the virgin ramdisk will be created.
It is this method that is used to retain information about seismic parameters, static IP addresses,
cron tabs and anything else which may be added or changed on a GS once it leaves the factory.
4.7 Timing
The GS achieves time synchronisation through regular time updates - digital time updates
(DTU) and analogue time updates (ATU). Whether these are initiated by a controlling computer,
or autonomously using the onboard GPS is purely application specic.
The logic of how the GS_master code decides where to obtain this timing information from is
documented in the owchart of gure 2. The logic of the owchart may be executed repeatedly
(at a certain interval e.g. 10 minutes) if previous attempts to initialize timing resulted in the
default time being set. This may happen if the GS detects that it has a GPS module connected,
but that the GPS antenna is not seeing enough satellites at startup.
Figure 2: Flow chart of the GSs timing initialisation process.
11
In fact the answer is that there is no limit other than storage space.
5 External Devices
5.1 Intelligent UPS
All GS units are shipped standard with a GS-compatible intelligent UPS
12
(iUPS), which is
internally equipped with a 1Ah sealed lead acid battery. The iUPS accepts mains power (110-
230V at 50-60Hz), which is regulated and used to power the GS under normal conditions. In
the event of a mains power failure, battery operation resumes until either the battery discharges
to a predened critical level, or mains power returns. If the battery reaches the critical voltage
level before mains power is returned, the iUPS will disconnect its load (i.e. GS) and power itself
down until such time as mains power is restored.
The iUPS is a hot-pluggable device and requires no conguration or setup parameters at GS or
RTS level.
5.1.1 iUPS Modes of operation
Each state transition detected by the iUPS (e.g. mains power failure, battery voltage critical)
is communicated to the GS, which in turn will take appropriate action, e.g. report state change
to CC, backup unsent seismograms, etc.
12
Uninterruptable Power Supply
5.1.2 iUPS connectors
Connector Name Function
1 Fuse
Holds over-current
protection fuse
2 AC Input
Receives 110/220 Vac,
50-60Hz
3 DC Output
Regulated DC output
voltage and
communication (to GS)
4 Switch
Turn AC input and DC
output (2 & 3) on/o
5.2 External Storage
The GS is capable of logging triggers to external storage via the USB interface. All that is
required for the GS to log triggers to external storage, is for an external USB storage device
13
with sucient free space (more than 5% of its total capacity) to be connected to the GSs USB
connector before power up.
The way in which the GS deals with external storage is detailed below:
If the GS has been given sucient time to start its data acquisition code, the GS will
auto-detect and mount the rst detected externally connected drive.
By default the GS will log all triggers to this drive. If the drive is inserted after the GS
13
The storage device should be formatted with either of the Linux ext2/ext3 or Windows FAT32/VFAT lesys-
tem.
data acquisition code has started, the GS will not detect it and will not mount or log
triggers to it.

GS Technical Manual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

GS Technical Manual

Hochgeladen von

Copyright:

Verfügbare Formate

Geophysical Seismometer

Das könnte Ihnen auch gefallen