GS Technical Manual

8/12/2019 GS Technical Manual

1/28

Geophysical SeismometerTechnical Manual

Gareth GoldswainISS International Limited

January 2010

1


2/28

Geophysical Seismometer Technical Manual 2

Contents

1 Introduction 6

2 Hardware Overview 62.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 Dataflash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Digitizer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.1 RS232 modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.2 FSK modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.3 RS485 modem module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Sensor Identification 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 specific firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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


3/28


4.3 Basic parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Communication sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.1 Boot sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.2 IPL sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.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 Configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.6.1 Configuration 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



4/28


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.

CCCentral Computer.

Client An application or system that accesses a remote service on another computer system.

CMPCommand Message Protocol.

CommsCommunications.

DaemonA computer program that runs in the background, rather than under the direct controlof a user.

DataflashA low pin-count serial interface for flash memory.DMA Direct Memory Access.

Downlink Communications link from central computer to device.

DTU Digital Time Update.

EthernetFamily 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 usersof the 2G cellular communication systems global system for mobile communications (GSM), aswell as in the 3G systems.

GPS Global positioning system.

GSGeophysical Seismometer.

HostnameA 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 first 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 Linuxkernel.

MAC Address A unique identifier assigned to most network adapters or network interfacecards.

Nameserver A computer consisting of a program or computer server that implements a name-

service protocol. It maps a human-recognizable identifier to a system-internal, often numeric,identification or addressing component.



5/28


NTP Network Time Protocol.

NTPD Network Time Protocol Daemon.

Operating SystemAn 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 actsas a host for computing applications run on the machine.

Piezoelectric Sensor A device that uses the piezoelectric effect to measure pressure, acceler-ation, strain or force by converting them to an electrical signal.

PPS Pulse Per Second.

RAMRandom Access Memory.

RamdiskA block of RAM that a computers software is treating as if the memory were a diskdrive.

resolv.conf The name of the configuration file 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 defining the electrical characteristics of drivers and receivers for use inbalanced digital multipoint systems.

RTSRun Time System.

Server A computer system that provides essential services across a network, to private usersinside 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 different computer architectures.

UNIXA computer operating system.

UplinkCommunications link from device to central computer.

USBUniversal Serial Bus.

Web ServerA computer program that delivers (serves) content, such as a web page, using theHypertext Transfer Protocol.

WiFi A class of wireless local area network (WLAN) devices based on the IEEE 802.11 stan-dards.



6/28


1 Introduction

The GS is the fifth generation of digital seismometer forming part of the Integrated SeismicSystem (ISS).

The GS is designed to be used in one of two modes, network mode or standalone mode1. Innetwork 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 andconfiguration parameters to, as well as collect data from remote seismometers. Data is bufferedinternally on the GS and transferred to the central computer upon request. In standalone mode,the GS obtains timing information via GPS and configuration parameters from internal flashmemory, thus obviating the need for a controlling computer. Data is recorded to external storagevia the USB port by default in standalone mode, and by configuration 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 identification module. All modules are interconnected via the mainboard,and interface to the outside world through connectors mounted on the backplate.

2.1 Block Diagram

1This is different to the QS which came in two distinct and divorced variants.



7/28


2.2 Mainboard

This board is analogous to the motherboard of a PC, it contains the CPU and all other peripheralcomponents required to provide the full functionality of the GS. Included on this board is RAM,

flash 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 withthe USB V2.0 Full-speed and Low-speed Specification.

2.2.3 Slow485

ISSIs adopted protocol for communication with external devices is dubbed slow 485, whichis based on the RS485 standard. It operates in a bus topology, and is provided along withDC power on one of the external connectors for connection to satellite devices. The slow 485protocol is developed and maintained by ISSI, but is an open standard and available to userswishing to interface with external devices.

2.2.4 FPGA

An FPGA is provided for clocking the digitizer module while filtering and timestamping digitaldata captured from it, and streaming this to RAM using DMA.

2.2.5 Dataflash

Onboard dataflash is provided for storing the GSs firmware and configuration parameters - adescription 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-quired2. All digitizer modules are 24-bit devices sampled at 48kHz. Lower sampling rates areachieved using downsampling techniques.

2.4 Modem module

Various modem modules are available for the GS, depending on the application and communi-cations requirements.

2Geophone, broadband, force balance or piezoelectric sensors are supported at time of writing.



8/28


2.4.1 RS232 modem module

This is the standard modem used for standalone applications as it includes an onboard GPSmodule necessary for timing requirements. The RS232 standard is a communications protocol

widely used by hardware manufacturers, allowing for a smooth interface between the GS andmost 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 lengths3

in wider networks.

2.4.3 RS485 modem module

Unlike the RS232 and FSK communication protocols, the RS485 protocol transfers data betweennetwork nodes via a half duplex bus. Owing to the bus topology of the standard, the RS485modem module supports two downlink connections (left link/right link) which may be usedto extend the bus. Each module thus acts as a repeater, relaying data between nodes of thenetwork.

2.5 Sensor Identification 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. Thesensor identification module provides an interface between CPU and sensor, providing power to

the sensor electronics and implementing the Smart Sensor communications protocol. The GS isthus able to gather information about connected sensors and relay it to the CC.

ISS Smart Sensors are hot-pluggable devices, and require no configuration or setup parametersat GS or RTS level.

2.6 External Connections

The GS has ten external connectors, the function and position of each is detailed below:

3Up to 7km.



9/28


Connector Name Function

1 Seismic 13 seismic sensor channels,

smart sensorcommunication

2 BNC GPS Antenna External GPS antenna

3 EthernetSupports 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 busdownlink

7 DC PowerDC power input and

intelligent UPScommunication4.

8 Comms Downlink(R)

RS485 communication busdownlink

9 Comms Uplink

Communications with

central computer(RS232/485, FSK)

10 Seismic 23 seismic sensor channels,

smart sensorcommunication

2.7 GS Cable Wiring

The wiring side of the connectors which mate with the GS chassis are detailed in the following

diagram:



10/28


3 Firmware Overview

Each GS is pre-loaded at the factory with a serial number, bootloaders, an embedded versionof the Linux operating system (OS) and all the latest ISS seismometer firmware. The OS andconstituent software package versions are tightly controlled by ISSI, and have been tailored tomeet the specific 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 astate which is appropriate for a more sophisticated operating system to take control. Thesebootloaders perform extremely low-level tasks such as configuring and initializing the hardware,



11/28


and are of little interest to the end user. They are discussed briefly below for completeness.

3.1.1 I-boot

An ISSI proprietary Initial Bootloader (i-boot) is used to initiate system memory and dataflash.Functionality is minimal and hands over control to the next level bootloader after approximately5 seconds.

3.1.2 U-boot

An open source Universal Bootloader (u-boot) provides extended functionality, providingservices such as tftpboot and writing to dataflash. The u-boot project page is located athttp://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 indataflash 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 Linuxkernel is present, but anything not specifically required has been stripped.

The OS together with its associated ramdisk (i.e. filesystem) are stored as read-only, compressedimages in on-board flash memory. These images are uncompressed and reloaded in their originalform each time the GS is rebooted. For this reason any files written to RAM will be lost upon(soft or hard) reboot.

Most of the basic utilities and services of UNIX-type systems (e.g. file copying, external storagemounting, networking services, etc.) are supplied in the form of a multi-call binary dubbedBusyBox5. Some of the more useful services are discussed in the following sections.

3.2.1 Networking

Each GS, unless specifically requested otherwise, is shipped with the default, static networksettings 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 different network settings to these defaults, including obtaining dynamicnetwork settings from a DHCP server using an onboard DHCP client (udhcpc) to implementthe Dynamic Host Configuration 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 IPaddress 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 fields, and click "Apply".

5The version of BusyBox supplied with the GS is version 1.2.2. See http://www.busybox.net for details and

documentation.



12/28


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-configured user is defined on the GS. For the username and password usedfor SSH authentication purposes, or to configure a GS for automatic, passwordless authenticationusing 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 theGSs IP address (see section 3.2.1), the GSs web interface can be viewed. The GS web interfaceprovides 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 protocolallows 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 informationon NTP.

Note on operating system and services

Although the above mentioned Linux OS and plethora of system services exists on the GS, theyare 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 effectiveGS deployment or use.

3.3 Ramdisk

The ramdisk is a collection of files (including executables) organized in a tree structure in theusual manner that one would expect to find on a conventional PCs hard disk, the differencebeing that ramdisk files are, as the name suggests, held by a filesystem which resides in RAM.This means that unlike the modifications made to files on a PC hard disk, changes made tofiles of the ramdisk are lost with power, unless the changes are saved to flash and copied overthe original file which will always be loaded from the same read-only image at boot time 6. Themethods used to retain changes to ramdisk files are discussed in sections 10 and 4.6.2 of thisdocument.

The ramdisk contains all the usual UNIX directories (/etc, /usr, /rootetc.) and a couple GSspecific directories. It is implicitly mounted by Linux at/ as the root filesystem before anythingelse.

6The ramdisk image is loaded by the u-boot bootloader (section 3.1.2) at boot time.



13/28


3.4 Flash

There are two banks of dataflash on the GS mainboard which are divided into a number ofpartitions. Each partition is intended for storage of specific data, detailed in table 1.

Table 1: Flash partition table.

Flash bank Name Data Size

Linux mountpoint (filesystem)

0 i-boot bootloader 17k n/a

0 u-boot bootloader 293k n/a

0 filesys ramdisk 7.5M n/a

1 code GS code 1M /mnt/code (jffs2)

1 jffs2 general 1M

/mnt/jffs2

(jffs2)1 kernel Linux 2M n/a

1 data sgram backup, configs 4M /mnt/data (jffs2)

3.5 GS specific firmware

The GS specific directory structure as defined in ramdisk at time of writing is tabulated in table2.

Table 2: GS specific directories in ramdisk.Directory Files/purpose

/root/gs fifos for IPC, _v0 files, 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 firmware 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 flashpartition (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 asimple copy during the boot sequence, (cp -af /mnt/code /root/gs), all GS code in flash iscopied over the ramdisk versions in RAM. The original code in the ramdisk thus serves as a kindof redundant backup, i.e. should the code flash partition become corrupted, the original codepackaged in the ramdisk can still be executed.



14/28


3.5.1 /root/gs

A few files constitute the minimum firmware requirements for a GS to automatically bootstrapitself to life by downloading code from CC. These files appear in the /root/gs directory in

ramdisk and are considered stable and trusted. They are never overwritten with newer versionsin flash and have the suffix _v0 to indicate that they are version zero files. Table 3 describesthese files.

Table 3: Files in the /root/gs directory (essential and _v0 files)._v0 file Purpose

getser_v0 standalone executable to fetch the GSs serialnumber

calc_checksum_v0.arm standalone executable to calculate the checksumof the basic parameters

chk_checksum_v0 standalone executable used to verify thechecksum of the basic parameters

run_gs_v0 daemon script responsible for keeping the mainGS code running

GS_master_v0.gz gzipped version of the main GS code

gs_helper_v0.sh script used for IPC

gs_fifo.cmd fifo special file used for IPC

gs_fifo.rsp fifo special file used for IPC

The/root/gsdirectory also serves as the general working directory for all GS specific tasks. Allseismogram and other temporary files created by the main GS application code appear beneaththis 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 theworking directory (/root/gs) at run time from where it is executed. This code is responsiblefor running all trigger algorithms, communicating with CC and is essentially the heart of theGS.

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 file is named according to the convention: pld__v.bin.whereSRATE1/2are 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 oneach seismic input. Also contained in this directory is the default FPGA code contained in theoriginal 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. Scriptsto program the FPGA, send messages on the slow 485 bus, check the sampling rate, fetch the



15/28


serial number etc. appear here. Many of these files are useful debugging tools. The followingtable describes these files.

Table 4: Files in the /root/gs/code/utls directory (GS utili-

ties).

.gs_utls_info a text file which holds information about the tarball whichthe current utility files were extracted from

.gsrc a text file which contains the default environment variablesused to control some of the runtime parameters of theGS_master code

calc_checksum.arm calculates the checksum of a given file , andwrites the binary checksum value to a file named.chk; useful when changing values in the boxconfiguration file, which then needs to have its checksum

re-calculated for the run_gs daemons validation purposeschk_checksum validates the checksum of a given file against

the binary value found in a file named .chk ifit exists

deccnt decrement the ASCII count value in a file

etc a directory used for configuration settings; obsolete in GSsmanufactured after May 2008

getcnt get the ASCII count value in a file

getsensdata fetches the sensor identification information stored on thesensor ID daughter board

getser fetches the GSs serial number stored on the sensor IDdaughter board

gpsdate sets the system time as obtained from the GPS module

gpsstat displays GPS statistics such as the number of satellitesbeing tracked, fix quality and position coordinates

gpstime displays the time as obtained from the GPS modulewithout setting the system time

gpsutl multicall executable for gpsdate, gpstime and gpsstat

gs_helper.sh a script which runs bash commands written to the namedpipe /root/gs/gs_fifo.cmd and writes the return code tothe named pipe /root/gs/gs_fifo.rsp

gs_portal.sh a daemon script (which is started by the GS_master code ifso configured) which persistently copies seismogramslogged to disk and health data to a remote server using theSSH protocol

gsipconf.sh an interactive script used to configure the GSs networkingparameters

inccnt increment the ASCII count value in a file

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



16/28


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 necessaryconfiguration and executable files 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 anddisplays the response - helpful for checking the UPSshealth

3.6 GS startup procedure

Once the OS has started all essential services, a hardware probe is performed to determine theboxs serial number7. If a valid serial number is found, therun_gsdaemon script is automaticallystarted. A flow chart documenting the logic of the GS run script appears in figure 1. Withouta 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.

7Each GS has a unique serial number embedded into internal EEPROM at the factory during production.



17/28


Figure 1: Flow chart of the GS run script.

4 Communication

When running in an RTS supervised seismic network, the GS is completely configured and con-trolled by the RTS using the command message protocol (CMP), over a digital communicationslink. In standalone mode, where the GS acts autonomously, a communications link betweenGS and CC is also necessary for configuration and setup purposes. The communications linkbetween GS and CC is therefore a vital part of the ISS and essential for GS operation. Infact, in RTS supervised mode, the communications link is always the bottleneck as far as data



18/28


throughput is concerned, which is why it is of the utmost importance to always use the highestquality 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 ISSCommand Message Protocol (CMP). Briefly, 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 databyte

...Lastdatabyte

Checksum

Description

UniqueID ofCMP

message

UniqueID of

station

CMPmessagespecific

data

...

CMPmessagespecific

data

Errorchecking

Usually, messages from CC to box are referred to as messages, and those from box to CC asacknowledges (acks).

4.2 Communication Options

The GS is available with a number of different digital communications options. Besides theprotocols 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 digitalcommunications equipment (e.g. WiFi, HSDPA, DSL modem, etc.) with an Ethernet interfaceis 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 sufficiently accurate

8

means of time syn-chronisation via the GS Ethernet port. Instead each GS must achieve time synchronisation eithervia GPS, available on the internal RS232 module, or via the RS232 modules serial port interfaceusing the standard ATU mechanism. Either way, any GS intended for Ethernet communicationsmust be equipped with an internal RS232 modem module.

xDSL

ISS branded external Digital Subscriber Line (DSL), modems specifically designed to pass theATU signal (regular DSL modems block it) are available from ISSI, and are particularly usefulin underground applications where timing cannot be obtained via GPS.

8An accuracy of sub 10sec is necessary for microseismic arrays, which is unattainable using even NTP (section3.2.4).



19/28


4.3 Basic parameters

All GSs are shipped preconfigured 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 configuration parametersare stored in the boxs unique configuration file created using the boxcon or jconfig programson the RTS host computer. This file, known as the boxfile, holds all essential parameters neededby the GS to configure 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 resolvesfor the hostname centralsite. How the GS resolves this name and obtains its own IP addressis dependent on the network configuration chosen. Section 3.2.1 stated that the recommendedway of configuring a GSs Ethernet/networking parameters such as IP address allocation wasvia the DHCP method. Should a static IP configuration be required however, this needs to beconfigured by remote login or via the browser interface. A number of files need to be written

to flash to ensure that upon next reboot, the network interface is brought up with the desiredsettings. A script entitled gsipconf.sh included in the utls tarball (section ??) of the GS isa useful interactive tool for creating these files in the correct format and saving them to thecorrect location.

4.4 Communication sequences

Most of the possible message sequences between CC and GS at time of writing are broadlydescribed below.

4.4.1 Boot sequences

The boot sequence is only used until the GS has valid basic parameters and code9. Essentially,each time the GS boots and finds a valid serial number (as described in section 3.6), it checksits basic parameters and code for validity and then either initiates the BOOT sequence or theNORMAL startup sequence.

The decisions governing which sequence is initiated are made by the run_gsdaemon detailed infigure 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) codewith the -bargument:

GS sends a QS_BOOT10 message, using default basic parameters (see table 6).

CC returns a QS_BOOT message with the basic parameters as configured in the boxfileon the RTS computer with corresponding serial number.

The GS_master(_v0) code exits after saving the basic parameters to flash.

9Unlike earlier generation ISS digital seismometers, the GS requires 3 separate lots of code - cpu code, pldcode and utilities code. See section 3.5.

10QS 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).



20/28


Code request boot sequence

If the GS has valid basic parameters but no valid code, the run_gs script will invoke theGS_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 flash, and the appro-priate code type flag set

CC sends CODE (block 1)

GS acknowledges

CC sends CODE (block 2)

GS acknowledges

...

CC sends CODE (block n) with last block flag and checksum

If the checksum is valid, GS_master(_v0) burns the downloaded code to flash and exits

Table 6: GS default basic parameters.Parameter Default value

baud rate 115200

parity none

databits 8hardware 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 ParameterLoad) sequence with CC:

GS sends RESET

CC returns:

SET_POLL

SET_DATETIME

QUERY_BOX

UNIAXIAL

A2DPARMS



21/28


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 nextmessage. 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 inthe IPL sequence (QS_SETUP), triggers the GS to save these to flash.

Table 7: IPL messagesIPL message Purpose

SET_POLL Set boxs polling parameters

SET_DATETIME Update boxs digital time (DTU)

QUERY_BOX Query boxs serial number, A2D module typeand sampling rate

UNIAXIAL Configure boxs sensor configuration

A2DPARMS Set boxs sample rate (may initiate pld codedownload sequence)

SUB_SENSITIVITY Configure 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 parametersand configure triggered/continuous operation

END_EVENT Set the boxs de-trigger level, and min/maxseismogram length attributes

GMP_SETUP Configure the GMP logical channels reportperiod

STP_SETUP Configure the STP logical channels parameters(e.g. trigger level, min event length)

BOXPARMS1 Set the maximum size of seismograms that areallowed to be sent in, and the maximumnumber of seismogram buffers

STAT_UNIAXIAL Request the version of boxs firmware and pldcode versions

POWER Request the boxs power information

QS_SETUP Set the boxs seismic network parameters (e.g.site IDs, net ID) and logging parameters



22/28


4.4.3 Trigger sequence

When a GS triggers, the trigger information is communicated to CC to enable the RTS toperform 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 buffer (i.e. seismogram has de-triggered, adaptive decimationis 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 flag 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, SENDBLOCK 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. Ifthe acknowledge is not received before the timeout expires, the message is resent. After afew unsuccessful attempts, the CC will indicate the station as inactive and will try to RESETthe station. The station has timeouts on RESET and RESULTS DATA and will continue tosend these messages until communications is established. The station has a graceful return toRESULTS DATA if communication is lost while transmitting a seismogram, giving as muchopportunity for recovery as possible.



23/28


4.4.5 Uninitiated CMP messages

A number of messages are sent by the GS not directly responding to messages received fromCC, 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 buffer ready tosend

GMP_RESULTS Sending of GMP data

STP_RESULTS Sending of STP data

CLEARB_BUFFER GS made decision to clear a seismogram bufferand has cleared it

ATU Acknowledgment of receipt of the analoguetime 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) tosend 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 inputsQS_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

offline 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



24/28


25/28


4.6.2 System data storage

This document has emphasized the fact that any permanent changes to the ramdisk need to bestored in flash 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-specific data will be retained) and is the largestavailable partition mounted within Linux.

Because it is impossible to anticipate all possible directories in which data different from that ofthe virgin ramdisk may be required11, a directory /mnt/data/config/sys is tested during theLinux initialisation scripts, and if it exists, its contents are copied recursively to the /directoryin ramdisk. Thus, any files/directories which appear below this directory in flash will appearin ramdisk with the leading /mnt/data/config/sys removed from their path. Any files whichexist both in the virgin ramdisk and in flash will thus be overwritten, and any files which do notexist 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 specific.

The logic of how the GS_master code decides where to obtain this timing information from isdocumented in the flowchart of figure 2. The logic of the flowchart may be executed repeatedly(at a certain interval e.g. 10 minutes) if previous attempts to initialize timing resulted in thedefault 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.

11In fact the answer is that there is no limit other than storage space.



26/28


5 External Devices

5.1 Intelligent UPS

All GS units are shipped standard with a GS-compatible intelligent UPS12 (iUPS), which isinternally 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. Inthe event of a mains power failure, battery operation resumes until either the battery dischargesto a predefined critical level, or mains power returns. If the battery reaches the critical voltagelevel 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 configuration or setup parameters at GS orRTS 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 changeto CC, backup unsent seismograms, etc.

12Uninterruptable Power Supply



27/28


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 OutputRegulated DC output

voltage andcommunication (to GS)

4 Switch Turn AC input and DC

output (2 & 3) on/off

5.2 External Storage

The GS is capable of logging triggers to external storage via the USB interface. All that isrequired for the GS to log triggers to external storage, is for an external USB storage device13

with sufficient free space (more than 5% of its total capacity) to be connected to the GSs USBconnector before power up.

The way in which the GS deals with external storage is detailed below:

If the GS has been given sufficient time to start its data acquisition code, the GS willauto-detect and mount the first 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 filesys-tem.



28/28


data acquisition code has started, the GS will not detect it and will not mount or logtriggers to it.

Date post:	03-Jun-2018
Category:	Documents
Upload:	henry-galvez-angel
View:	233 times
Download:	0 times

GS Technical Manual

Documents