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.
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.
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
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:
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.
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:
Want a union of data in input files without any duplicate blockettes
telemetered epochs may span multiple records but each record will contain at most one epoch.
The 4K records may contain portions of multiple records.
The time in the MiniSEED FDH (Fixed data header) is not necessarily the time of the data (OS9 time) Time may be off by seconds to minutes
The user cannot rely on the time in the MiniSEED FDH to determine if the record contains the desired data. The user may not get data precisely at desired starttime if only copy of data is in 4K byte record and may get additional data after endtime if data are taken from 4K byte record
Merging is complex.
Each record has a unique number that starts with 0 with every reboot and goes to 2**(31-1).
There are problems in the merging of the Blockette 2000 data
if GPS program restarts on Quanterra the resetting blockette number to 0 (Joe suggested always incrementing the number)
UTC time is not the same as GPS time (no leap second in GPS).
The GPS ASHTECH does not release information about the commands - no documentation available.
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.
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.
It operated for 88 days continuously with no data gaps.
The input terminated noise was very low for long-period/broadband seismic applications.
Non-linearity did not limit large signal performance.
The instrument time-tagged the data with respect to the digitizer input to considerably better that 1 millisecond (»5msec). The standard deviation of time-tag accuracy drift was 3.8 microseconds over 7 days.
The seismic Signal Resolution and Seismic Signal Noise tests indicated that the resolution and noise of the Q730B-bb digitizer were below the USGS New Low Earth Noise Model (NLNM) for use with a Geotech KS54000 seismometer.
The Q730B-sp was designed to interface to a Geotech GS-13 seismometer.
It operated for 24 days continuously with no data gaps
The input terminated noise was very low for short-period seismic applications
Non-linearity may be a limiting factor for large-signal performance. The distortions from non-linear performance could add to the digitizer noise floor, decreasing the signal-to-noise ratio.
It time-tagged the data with respect to the digitizer input to better than 1 millisecond. (»340msec).
The calibrator correctly programmed sine amplitudes and frequency, step amplitude and duration and white-noise/random binary functions.
The SSR and SSN tests indicated that the resolution and noise were below the USGS NLNM for use with 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.
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:
comserv: reliable delivery from stations into a comserv memory area
mserv (modified version of comserv): receives multicast MSEED packets and puts them into comserv memory area
cs2Mcast: comserv client that reads a comserv memory area and multicasts MSEED packets. This is used to redistribute packets rx'd by comserv.
a2mseed: reads analog data from an earthworm ring, reformats the data into MSEED packets, and multicasts them onto WaveNet.
Mserv's modifications to comserv:
multicast socket options added to UDP sockets
no acknowledgement of packets done by mserv
packet type received by mserv is 512 byte MSEED packets
ALL packet types (data, triggers, SOH, log) are based on 512 byte packets. Comserv shared memory area for a station differs from an mserv shared memory area for a station
Packets are sorted into types and appropriate comserv bins using MSEED header or blockette information
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:
Based on comseve and datalog. Use with other acquisition systems is questionable
Software is written in C++ with significant use of Standard Template Library.
WaveClient ARI in C++
Rapid Wave Servers use significant RAM
Rapid Wave server configuration must be maintained.
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)
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).
All changes in the code are documented using Source Code Control (RCS). It is ISTI's hope that the public RCS tool is used to continue to maintain the code versioning
ISTI will provide documentation on the changes
Byte Swapping: the plan is to keep all byte-swapping in the comserv server core to prevent having to rewrite every client. By keeping the byte-order native to the host computer, the client's code need not be modified.
The standard MSEED data byte-order is difficult since this issue has not been addressed by the federation. It was proposed to change the "D" in the fixed section of the data header to "d" when the data are in little-endian (Intel) byte order. This assumes that all data now are in big-endian. It was the general consensus to keep the header and the data in the same byte-order - whatever it is.
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
Station Operation Manager (SOM) which provides a number of tools for station and network setup, control and monitoring.
datadump - control disk space and dumps data to tape
qplot displays data traces on screen, printer or in files
CD-R data storage package
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.
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.
Quanterra - 330 Data Engine
appearing in March 2000.
Features:
6 -24 bit channels with up to 4 simultaneous rates per channel.
4 physical and 4 logical ports (3 serial 1 ethernet)
Able to handle wide temperature range (-40C, +70C)
Software programmable flexible timing modes, accurate timing and true phase lock,
Ultra low power (~1W)
Open interface with complete documentation of communication interface
Calibrator is similar to the Q4120 which can be managed by remote controlling system.
Can turn off power for unused channels
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.
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
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?
ACE: has entries when the satellite reception varies and there are changes in quality. The message in the ACE log indicate unexpected timing events (e.g. 1PPM is NOT on pulse)
FC: the VCO related values used to determine initial VCO value. There are diurnal variations and seasonal variations. This value might indicate a failing oscillator or a change in the environment.
CD: Value at LP rate is in mseconds. Amount by which system is correcting the time. This value may start to move when the satellite is lost. It is not good to see this value continuously increasing. It usually levels out around ±30. When the Phase Lock is locked it will NOT go above 30. If the quality is ³ 3 the time is correct. If the Drift continues to increase, the PL is not controlling the value OR the VCO is not correct. In a Q680 the only adjustment can be made in the VCO. In the Q4120 and Q730, it can be physically adjusted with a screw driver.
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.
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