QUG meeting 12/10/99-12/11/99 Berkeley, CA


The Proposed Agenda:

Friday, December 10, 1999

8:30 Introduction, agenda updates, proposal of QUG statement of purpose

8:45-9:00

Quanterra and KMI merger

What it means for Quanterra, KMI

What it means for the Quanterra user community

9:00-noon

MShear - Quanterra (Steim), Busby

Current status

Key system for configuration

What can and cannot be done with key system

Guidelines on designing local macros and key files

Update and distribution mechanism

Discussion

1:00-1:30

Hardware evaluation: Analysis of Q730B system - Kromer

1:30-2:30

Software solutions and development

BRTT Antelope - Quinlin

Comserv et al - Maechling , Neuhauser

Comserv on other platforms - ISTI, Hanka

2:30-3:30

Digital data sources into Quanterras

Digital pressure, windspeed and software - McLafferty, Hutt

GPS data acquisition under MShear - Krukar

GPS data acquisition, handling GPS data at the central site- Neuhauser

4:00- 4:30

CTBT issues for Qunaterra networks

Butler, Hutt, KMI/BRTT

4:30-5:30 - Open discussion


Saturday, December 11, 1999

8:30-9:00 Agenda updates, Discussion and adoption of QUG statement of purpose

9:00-10:00

New Quanterra Hardware Q330 - Quanterra (Steim, Reimiller)

Design overview

Software interface

Low power data recorder

Availability

10:00-10:30

IRIS/IDA - system overview - Davis

Network overview, instrumentation, datalogger, and telemetry

10:45-noon

Future recording systems:

Quanterra and KMI low power recording systems (Quanterra, KMI)

Open discussion by users group on requirements

1:00-1:15

Comlink tuning parameters - Hutt et all

How to tune comlink (dp->da or da->comserv) parameters

1:15- end

Network status reports, discussion on issues for networks, other open discussion such as documentation, Web presence, etc.


The Meeting:


To give Joe Steim a break from presentations all morning, some of the afternoon presentations were moved to the morning.


Doug Neuhauser proposed that the QUG adopt a statement of purpose. The proposed statement was: "A loose forum of users and Quanterra representatives that share experience and software." Rhett Butler objected to the word "loose", but there were no other noticeable objections. It was finally decided that the QUG would live with whatever Doug Neuhauser put on the WEB page.


  1. Quanterra/KMI


ISO9000 is an International Standard Organization that sets standard for all levels of business. These standards include customer relations, product management, documentation of manufacturer changes, etc. All serious companies are increasingly required to comply with ISO9000. The "CE" is the European equivalent of the International Standard Organization. Businesses must comply with their standards to do business with European companies.


Quanterra has no plans for altering the existing products - this includes the Q680, Q4120, and Q730. Eventually the older products will drop out when parts can no longer be purchased. Quanterra has made an effort to purchase sufficient number of products to prolong the life of the older systems.


In the Q680, it is suspected that Motorola will stop making the CPU boards. This will definitely be a problem.


Removable Disk Media (RDM) will probably replace the tape drives. The Q680 is still sold with DAT drives which do not work well in high humidity. ASL has conducted tests on alternative tape drives (WANGTECH 51000). These drives are a "drop in replacement" and work with the current OS9 drivers.


Joe will continue to provide software for those who need it. For the Q330 and new products, the internal software will not be available but the protocol to communicate with the Q330 will be fully documented and supported. Where it is helpful and necessary, Joe will supply the software.


MShear: For the duration of the new product development, there will be no new functionality in the MShear software. Quanterra will continue to provide "bug" fixes. By Quanterra's supporting coupled interface, the customer can provide his/her own software. Joe will take requests for modifications to the software and "put them on the list". However, it will be 1-2 years before the changes will be available.


  1. Bob Busby's presentation of the KEY documentation:


The latest revision for the KEY files is "Revision D". The newest Quanterra Manual contains appendices and a chapter on the key system and macromania. He suggested reading the appendicies from "back to front" to make them more easily understood. These manuals were distributed to the attendees. Revisions of the Key system files are: 0131, 0831, 0531, 0722, 0804 (this is the current revision that supports Q680, 4120, and Q730). The latest revision dated 1207 is under development. Features supported: tape drives, analog output, NSN, location codes, optional scaling of mass positions, component specific priorities. Unsupported (at present time) dynamic disk buffer size scaling, HUB configuration including split systems, FAX and email alerts, log channel. The HUB configuration is the driving force for dynamic disk buffer. There will be up to 3 HUBS (one server0 and three remote) - to have more would make the "hashing" too cumbersome.


MShear is required for Y2K compliance, but the key configuration scheme is not necessarily a part of MultiShear. The Key scheme was designed to be a scheme for saving memory. It was first introduced in Jan 1998 with the first trial in March 1998. The current MShear version release is 36/08 0531


  1. More from Quanterra:


There was a binary patch released in October of 1999. This patch is available at the QUG ftp site to fix a slip connection for a 4120. There is no serial patch for the Q680 at this time.


Improvements: There is a new clock program for the Q730B on selected systems. There is a bug fix for the prio=DEF in aqsample. There are new refinements to "ifslip" and ethernet support for the Q730. Release of new patches should be available in April 2000.


The "sreboot" command may not work correctly on some systems (4120 and 730). On Q680DV the expansion serial board does not respond to the reset. The "work around" is to use the sleep command after killing ALL processes. It was suggested that the user build a script that kills all processes, wait until they are dead and then do an "sreboot". It is particularly sensitive to ethernet activity. Therefore, all ethernet activity needs to be quiescent. If a device is "inized" it will not work. For Q680 with a 68000, a reset signal cannot be activated. The "break" (soft reset) will work. It was suggested that a device that will cycle the power could be installed. The 4120 must have a jumper in place on a CPU board for sreboot to work. When it does not work, nothing happens.


IV Digital Data Sources implemented in a Quanterra:


  1. Dave Krukar of ASL presented the work that he had done on interfacing a TRIMBLE and an ASHTECH with a Quanterra. He talked about encapsulating data from other instruments in a SEED record. His program allows the user to extract the information from the SEED record. The instruments are hooked up via a serial port. The ASHTECH requires hardware handshaking and odd parity. The user must specify the [AQBLK] section of the aqcfg file and this must be AFTER the [aqlcq] section. To verify Y2K compliance of the instrument, one needs to step through the menus on the TRIMBLE to see if the Y2K program is there.


There was a request for more command and control functions (e.g. manage a ring buffer) It was suggested that perhaps another serial interface for the C&C functions - but it is easy to use too many serial ports on the Quanterra. There is no ethernet on the Ashtech or Trimbal.


  1. Doug Neuhauser spoke about getting GPS data at the central site. The problem encountered was data are coming in from multiple sources. MSOMERGE was written to handle the data that are in opaque blockettes. The data in the opaque blockette are the exact data from the GPS. The opaque blockette is used to encapsulate and transport the data over miniseed records. The data are in a time series in miniseed. The GPS data have a 30 second sample rate. AQBLK puts the data into 512 miniseed record. These records are then used for telemetered data. Then the data are put into 4K byte records for local storage and "retrieve". The issues for merging blockette 2000 data from different files:


C. Sue McLafferty of ASL presented collecting data from a Paroscientific and Handar environmental instrument. She wrote "servXEN" which handles the multiple data streams. The timing is based on OS9time, so the OS9time should be close to the GPS clock. The system polls for a sample, so the timing is not accurate. It depends on sysmon keeping the OS9time close to the GPS time. There is some loss of resolution to obtain 1 sps data. With the MET3 we cannot get the samples every second. The data collected from the instruments were presented by Bob Hutt. There were time gaps that could be the result of sysmon resetting the OS9time to keep accurate time. When there is no wind, still get data from the digital device.


  1. Hardware evaluation - Analysis of the Q730B system - Dick Kromer


Dick Kromer of Sandia Laboratory presented the results of his tests run on the Q730B-bb and Q730B-sp borehole installation remote digitizers. These test were conducted in a laboratory, not in the field.


The Q730B-bb was designed to interface to a Geotech KS54000.


The Q730B-sp was designed to interface to a Geotech GS-13 seismometer.

The Q730B digitizers had performance to >23 bits at 40 sps. The digitizer system noise of the remote digitizer implementation was exceptionally quiet.


  1. Phil Maechling - Caltech - Multicast Comserv (mserv) in support of redundant RT Processing systems


Trinet (Cal Tech) has about 100 Quanterra data loggers installed. Phil has developed Quanterra related software to provide reliable data to the end user. On stations where there is sufficient bandwidth, there are two comserv processes running on the Quanterra data logger to send data to the primary and backup systems. Where there is insufficient bandwidth, one comserv running on the Quanterra supplies data to the primary acquisition system which in turn sends data via cs2mcast client to the secondary acquisition system Comserv clients can then obtain data from the secondary acquisition system. There are "failover" scripts to change which system (Spring or Jet) is primary.


Processes employed by this system:


Mserv's modifications to comserv:

Source code available for mserv, cs2mcast on CALTECH anonymous FTP site: ftp.gps.caltech.edu

pub/phil

file name cit-mserv.tar.

or at the QUG software archive site (ftp://ftp.ncedc.org/pub/quanterra)


Trinet WavePool-WaveServer:

This was developed as a possible way to transfer data between networks.

To achieve both immediate (RT) data availability and data that is up to 7 days old a system was developed that can provide both.

WavePool has RAM based array of packets and Waveform disk files built by datalog to provide a small amount of rapidly accessible storage and large amounts of less rapidly accessible storage. It is required to maintain 7 days of data and provide data at an access rate of 100 event requests per minute.

WaveServer retrieves data from WavePool. There are two WaveServers running on a data acquisition machine; one to access the Rapid WavePool (RWP on RAM) and one to access the Disk WavePool (DWP). Clients try the RWP first then the DWP if data are not available. The server is based on standard networking services so waveform data will be network accessible. Data can be saved to MiniSeed files for permanent archive.

Possible drawbacks to Trinet WavePools and WaveServers:


Rapid Wave Server and Disk Wave Server source code is available on Caltech anonymous FTP site:

ftp.gps.caltech.edu

pub/phil

File Name: cit_rws_dws.tar

or at the QUG software archive site (ftp://ftp.ncedc.org/pub/quanterra)


  1. Comserv on other Platforms:


A. ISTI's (Instrumental Software Technologies Inc.) comserv on Linux - Paul Friberg


ISTI (http://www.isti.com) is porting the latest comserv software release to Linux for a customer. The port will be folded back into the public release and will work with Solaris, OS9, and Linux. Software it being tested using SUSE6.1 Linux and Solaris 2.6 (using the GCC compiler).


ISTI also is working on a JAVA based operator interface to monitor the status of stations based on comserv.


B. GFZ Potsdam, Germany Winfried Hanka


The objective was to get a more flexible DP so GFZ ported version 14 of comserv to Linux. The system can be used as a Data processor as well as a data collection center processor or data distribution system.


New functionality include


Data are available to users through DRM (Data Request Manager) for telnet based interactive access, AutoDRM for email, and WebDRM for WWW based access.


In addition, seisd server daemon was written to support digitizers from manufacturers other than Quanterra.


See http://www.gfz-potsdam.de/geofon/qug/qug.html for further details.


  1. Danny Harvey from Bolder RT Technology


Danny spoke about the antelope system that was developed for the Air Force. There were a number of "sacred cows" for requirements such as high data quality and reliability and minimal cost of total ownership. Along with the high data quality were numerous calibration requirements. They used common "off the shelf" components to set up a prototype system. The Air Force did not like the MShear timing algorithm. KMI build a new cal board and preamp board. To assure data reliability there were 3 redundant computers used (Sun/Solaris systems). They did not use comserv but qt2orb instead. They repackaged the data for CIT requirements so they could not use MiniSEED.


  1. Quanterra - 330 Data Engine

appearing in March 2000.

Features:


The Q330 can be connected in various ways. The simplest connection is to have one Q330 and one packet baler, a self contained recording module which logs the data from the Q330. The Q330 periodically sends data to the baler via ethernet connection. It could also send data via a serial or the ethernet to an offsite data recording system. It could be a combination of a local baler and an offsite recorder.


Baler (Model 14 to be available in April 2000) features: low power on average (more used when reading and writing data), operate event detection, off the shelf hardware, Web capable. The packet baler will record data from the Q330 via either an ethernet or serial IP link. It records log messages (message log, detection log, and timing log) in separate files. It also allows alternate data stream inputs such as geodetic GPS or meteorological instruments. Data can be retrieved from the packet baler over the Ethernet interface using ftp or http. Removable media such as a removable hard disk are available in special cases


The major differences with MShear comm protocol:

Priority of channels - each logical port can have a priority level (so only 4 priorities)

Control flushing of data (old or new data)

Means of determining excess bandwidth (similar to MShear "flooding").

The MShear style of com protocol required an ACK for each packet and no out-of-order packets. Since packets must be received in order, a missed packet meant that not only did that packet have to be resent, but each subsequent packet had to be resent before the normal flow of packets could continue. With the new protocol, packets are allowed to be received out of order. If one packet is not received, it will be resent without having to resend each subsequent packet. The receiver will ACK all the packets except those that it did not receive and the sender will only need to resend those packets that did not get through.


  1. Pete Davis of IRIS-IDA to present "the other side"

IRIS-IDA has 36 stations from which they receive data. Most of them use a GS-13 or an STS-2 for higher frequency signals.

Data recorders:

Mk7ISP which is a pentium based CPU using Solaris OS. It uses low power (<200 Watts) and offers a variety of recording medium. (They have had problems with the DAT tape drives.) It can store 7-10 days of data on medium. Connections to all but 8 stations are by LAN, or dialup, or Lease Line. Data are telemetered using TCP/IP protocol or AutoDRM requests.

REFTEC data logger and NRTS PC workstation running Solaris


  1. General Discussion

Various topics were discussed in the last afternoon. These were:


Timing issues - these are much improved with MShear and GSP2 clocks which are both necessary for Y2K compliance.


How to verify the gain of the sensor? The only way is with a calibration.


How to track equipment? Beginning with the Q330 there will be UNIQUE serial numbers.


Timing messages - will be seen if there are problems (i.e. quality is < 3) What to do if there are observable errors but the quality is > 3?


Clock related channels - how to use these?


Leap Seconds - the GPS has chosen to ignore the leap seconds.


Mass Positions - these are not part of the digitizer. A "quality bit" associated with the channel that indicates that the associated mass positions are on scale might be helpful.


RT data - there is an ever increasing need for RT data. DSS is valuable but have to be on the network to use this. It is a high bandwidth internet application.


  1. QUG archive and web page.

    The QUG web page is: http://ncedc.org/qug

    The QUG software archive can be found using http or ftp.

          ftp://ftp.ncedc.org/pub/quanterra

          http://ncedc.org/qug/software


8