PB14 Baler Design Overview Quanterra, Inc. 325 Ayer Rd. Harvard, MA 01451
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 1
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
PB14 Baler
Design Overview
Quanterra, Inc.
325 Ayer Rd.
Harvard, MA 01451
THIS DOCUMENT CONTAINS INFORMATION AND TRADE SECRETS PROPRIETARY TO
QUANTERRA, INC. USE OF THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS
LIMITED TO ENGINEERING DEVELOPMENT AND MANAGEMENT PERSONNEL DIRECTLY
INVOLVED IN THE DEVELOPMENT OF THE PRODUCT HEREIN DESCRIBED. PHOTOCOPYING
OR ELECTRONIC TRANSMISSION OF THIS DOCUMENT, OR ANY MEANS OF DISSEMINATING
INFORMATION CONTAINED HEREIN WITHOUT THE PRIOR WRITTEN PERMISSION OF
QUANTERRA, INC. IS STRICTLY PROHIBITED.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 2
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
1. INTRODUCTION .............................................................................................................................................3
1.1 SCOPE OF DOCUMENT...................................................................................................................................3
1.2 RELATED DOCUMENTS .................................................................................................................................3
1.3 BALER COMPLIANCE ....................................................................................................................................3
1.4 THE Q330 FAMILY ........................................................................................................................................3
1.5 PB14 DESIGN GOAL - SIMPLE, SINGLE-THREADED NETWORK-AWARE STORAGE. .........................................3
1.6 PB14 OVERVIEW OF FUNCTIONAL REQUIREMENTS ......................................................................................4
2. DEPLOYMENT MODES & ILLUSTRATION OF REQUIREMENTS.....................................................5
2.1 CONNECTIVE/FUNCTIONAL MODELS: BALER APPLICATION EXAMPLES .......................................................5
2.1.1 Application example: Local Recording only .......................................................................................5
2.1.1.1 Implied Requirement: Means to seamlessly switch Balers used in field recording ......................................... 5
2.1.1.2 Implied Requirement: Continuity spanning power-up cycles & robust unattended operation......................... 6
2.1.1.3 Implied Requirement: Means to force flush pending data buffers to disk prior to Baler switch ...................... 6
2.1.1.4 Implied Requirement: "Attention" pushbutton................................................................................................. 7
2.1.1.4.1 Function of Interrupt Button: Concepts ..................................................................................................... 7
2.1.2 Telemetry Application examples..........................................................................................................7
2.1.2.1 Application example: Serial Telemetry with Local Baler................................................................................ 8
2.1.2.1.1 Implied Requirement: HTTP access to Q330 via Serial interface ............................................................. 8
2.1.2.1.2 Implied Requirement: Means to communicate to all remote devices: IP switching & data recovery........ 8
2.1.2.2 Application example: LAN-based Telemetry with Local Recording............................................................... 9
2.1.2.3 Application example: Minimum-power continuous LAN access to Q330 with power-cycled Baler............... 9
2.1.2.4 Application example: Remote Digitization with Telemetry to WAN Access Site........................................... 9
2.1.2.4.1 Implied Requirement: Intelligent IP address assignment and retention..................................................... 9
2.2 STATION-LEVEL INTERCONNECTION ..........................................................................................................10
2.3 BALER FUNCTIONS......................................................................................................................................11
2.3.1 Modes of Operation ...........................................................................................................................11
2.3.2 Levels of Baler Compliance...............................................................................................................11
2.3.3 Baler status ........................................................................................................................................12
2.3.4 Baler Power cycle control .................................................................................................................13
2.3.4.1 Baler power up: implications for Q330 functions .......................................................................................... 14
2.4 WHOLESALE Q330 & BALER PARAMETER SETUP AND DATA RECOVERY: QNET "SEATS" .......................14
2.4.1 Staging Area Activities ......................................................................................................................15
2.4.1.1 Q330 Configurator ......................................................................................................................................... 15
2.4.1.2 Baler Configurator ......................................................................................................................................... 15
2.4.1.3 Data Vacuum ................................................................................................................................................. 15
2.4.2 Implications for Address Management ..............................................................................................16
2.4.2.1 Assignment on Serial and Ethernet Interfaces. .............................................................................................. 16PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 3
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
1. Introduction
1.1 Scope of Document
This document is the Engineering Design Specification for the Packet Baler Model 14, or PB14 Baler ™ Data
Processing and Storage Module, or PB14. It will be revised during the design process, and serve as the final
technical description of the product. Each item is listed as a required feature, or, where applicable, as a minimum
requirement or a “goal”, the realization of which depends on cost, availability of physical processing resources, and
implementation complexity. This document concentrates on the detailed functional specification of the PB14, and
attributes of all "Baler" devices. Functional requirements of modules operated in conjunction with the PB14, in
particular the Q330 Data Engine ™, are discussed where interface considerations or partitioning of functions may
be important.
1.2 Related Documents
A number of documents are relevant to this product and are listed below. Some documents are open distribution.
Others may contain proprietary information, and are considered company private. These documents are revised
from time to time. Current versions should be consulted for detailed information.
• Q330 Advance Product Disclosure - describes family features with a market perspective.
• Q330 Design Document - describes the detailed design of the Q330 Data Engine
• Q330 Communications Protocol - communications protocol to which PB14 adheres.
• Q330 DP Writers Guide - guide to logging Q330 data.
- functional specification for "Baler Compliance" including web pages:
status.htm, info.htm, retrieve.htm, baler.htm
• PB14 Baler File Structure - defines file-level access to PB14, and contents of baler initialization and
continuity files baler.ini and station.ini
• Q330 DP Token Definitions - defines DP configuration tokenization for "Baler Compliance"
• CMEX Programmer's Reference Manual - for Certified Software CMEX kernel controlling PB14.
1.3 Baler Compliance
This document also contains references to the specifications that define "Baler Compliance". Devices not meeting
this standard will not be designated as a "Baler". One particularly important aspect of Compliance is in the means of
accessing recorded data. At the broadest user level, data access is a request by time and SEED channel of a
particular data segment. Balers of totally different internal design may achieve a high degree of compatibility at this
level. Compliance is achieved through adherence to a minimum standard for data access over an IP network to data
recorded in the Baler. An HTTP request to recover data from a Baler, defined by the retrieve.htm page in the Q330
DP Writer's Guide constitutes the minimum standard for "Level 3" Baler Compliance. See subsequent section on
"Levels of Baler Compliance."
1.4 The Q330 family
The "Q330 family" includes a number of modular products comprising a comprehensive set of tools for building
seismological data acquisition systems according to various operational models. Modules may be selected to create
a network of remote stations telemetered to a central site, or a group of autonomous recording systems. Interfaces
will be available for various common types of communications systems, including IP network, radio, pager, and
VSAT telemetry. The family of modules addresses the functional requirements of every major known type of
seismological instrument deployment outside the geophysical exploration market. The Q330 family constitutes a
"core platform" for a broad range of application areas. The Q330 and some family elements are covered in other
documents.
1.5 PB14 Design Goal - simple, single-threaded network-aware storage.
The PB14 is the first in a series of planned Packet Balers. The PB14 is intended as an IP network-aware recording
accessory for the Q330. The PB14 may receive and store the data from a single Q330 data source. The PB14 can bePB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 4
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
power-cycled, and may receive data in bursts from the Q330, via Ethernet or a serial SLIP interface, to be logged to
internal IDE-compatible disk or solid-state memory. The resultant low operating duty cycle permits an average
power consumption of roughly 1-5% of the static power, which is 6W. The Q330 and PB14 together form a very
low power broad band recording system suitable for remote deployments. The modularity of the Q330 and Packet
Baler allow physical separation of the units, by wire or wireless telemetry. Data are recovered from the PB14 using
an industry-standard HTTP protocol that allows specification by request time and SEED channel, or by access at the
file level. The PB14 will provide recording of continuous data streams, and provide event triggered recording, as
available CPU capability permits. The PB14 is constructed with industry-standard COTS PC-104 hardware, for
minimum development time and cost. The essential value of the PB14 is as a fully integrated accessory to the Q330.
d a ta a n d c o n tro l P a c k e t B a le r
Q 3 3 0 D a ta E n g in e
IP p ro to c o l re c o rd in g s y s te m
P o w e r C y c le d
1.6 PB14 Overview of Functional Requirements
The functional requirements of this model include:
• Target average power of 0.1 Watts in duty cycled mode, from 12VDC nominal.
• Burst mode recording and incremental recording of continuous data from a single Q330 Engine.
• "Blind" operation, i.e. no parameter setup, permitting simple in-the-field PB14 "hot swap".
• Ethernet and Serial SLIP IP network interfaces with IP packet switching between them.
• Simultaneous recording and data recovery by HTTP time/channel request through network interface.
• Efficient time/channel request or file-level bulk data recovery, such as at a data playback center.
• Format conversion of data from Q330 packets to MSEED, and recording in MSEED.
• Generation of data that include all time "corrections", so that, in normal circumstances, no user post-
processing is required to correct timing errors or remove timebase "drift". Capability may be included in
the Baler to back-annotate data in order to correct poorly-timed contiguous data segments that may be
bracketed by intervals of good time reception.
• Recording of all status-as-a-function-of-time values from the Q330, sufficient to reconstruct the health of
the data acquisition and telemetry environment, including timing, communications errors, internal
hardware errors, and results of any internal calibrations.
• Reporting of hardware and software unit identification and unit tracking.
• Concise, complete reporting of the recording configuration of Q330 supplying data to the Baler.
• Report of Baler status, such as "fullness" of non-circular data buffer files, and file system errors.
• An internal 10Base-T 4 port hub that may be cycled along with the Baler's CPU. The hub permits
connections of the Q330-Baler LAN segment to an existing LAN.
• Power supervisory functions to prevent operation with out-of-tolerance primary DC power.
• Event detection based on Murdock-Hutt (including bandlimiting digital IIR filters) and THRESHOLD
detection schemes. One or a few simple "sensitivity knobs" may adjust all the event detection thresholds
wholesale, as in MSHEAR.
• Scheduled and on-demand ISP dialout and PPP link establishment. The poor man's internet gateway. This
feature is essential to enable wide deployment of Q330/Baler systems where internet access is limited.
• Low-cost "desktop" packaging - or "hardened" packaging for field applications.
• A low-power Device Management Unit processor, with bidirectional communications to the Baler's CPU,
and that supports CNP-packetized communications on a serial port for external control and monitoring.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 5
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
2. Deployment Modes & Illustration of Requirements
2.1 Connective/Functional Models: Baler Application Examples
The following application examples demonstrate expected modes of operation. In broad strokes, the Q330/PB14
combination is expected to be used in the following way;
1. The Baler 14 acts as local storage for data in the case that continuous telemetry is lost. Data would be
recovered on request for short segments when telemetry resumes or by Baler swap for long-term outages.
2. The Baler 14 and Q330 are operated without telemetry in an autonomous recording mode. This simplifies
many requirements. However most customers who desire this mode also want the same hardware to be
able to be used in a telemetry mode if available. Autonomous mode also is most severe in terms of
packaging and environmental exposure.
This section illustrates the types of deployments in which the
PB14 Baler functions should be compatible with the Q330.
LAN (hardwire)
Each application example illustrates one or more important
feature. The models show physical links as either dashed, WAN (internet)
indicating wireless, or virtually wireless (Internet), or as solid
Serial (hardwire)
lines indicating a wire between devices. In certain cases the
cabling will contain additional signaling out of band of Ethernet Serial (wireless)
or serial data, for instance to power up the baler. Power itself Power & Signal
may also be contained in the inter-module cabling. See the
"Station Level Interconnection" section.
The following examples, Terminal Equipment (TE) could be ISDN, Frame Relay, DSL, VSAT, digital radio,
analog microwave, or analog modem.
2.1.1 Application example: Local Recording only
The simplest application for stand-alone recording uses a Q330 with Baler attached on the Ethernet. For low power
operation, the Baler is power-cycled and data are sent in bursts, although the Baler may remain powered and receive
data incrementally. The QNET connector is sufficient to contain all required connectivity between the Q330 and the
PB14, including Ethernet, power and power on/off control.
QNET supports:
• 10BaseT network. logical 4: Baler Storage
Burst or Continuous TX
• Power cycling control of the Baler by the Q330. PB14 QNET Serial
• Current-limited (0.25A) unregulated 12VDC nominal
power. The power connection is optional, and may be used to
provide a minimum-cabling configuration. Diode switch losses
in the Q330 slightly reduce the efficiency of this mode of
powering the PB14, although if power to the PB14 is switched, Q330 QNET Serial Console
the average total power loss may be insignificant. The PB14
may also be powered through a separate power connector. The
Q330 may also be powered by the PB14. The QNET power "bus" is automatically bidirectional.
• Additional controls for special applications (see later this document)
• QNET on Q330 and PB14 are pinned identically. Direct connection requires a "crossed" 10BT network cable.
2.1.1.1 Implied Requirement: Means to seamlessly switch Balers used in field recording
A field operator will switch Balers to retrieve the full Baler for data playback without having to reconfigure
addresses or any other parameters in order for a new Baler to be dropped in the old one's place. The goal is that NO
explicit reconfiguration is necessary for either the Baler or the Engine to detect the switch. This goal cannot be met
in complex installations with multiple Balers and Engines on the same network segment and requires as a minimumPB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 6
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
the IP address be specified on the device prior to network connection. The mode of "blind" operation requires a
number of capabilities implicit in the PB14 software design:
• IP Address. The PB14 must receive an IP address assignment from a "host". The manner is defined in the
related protocol documents. The operation is similar functionally to BOOTP. Such address assignment is required
not only on a minimal LAN segment comprising only a Q330 and a Baler, but on any LAN where a Baler, or
number of Balers, is connected. Where more than one Baler is installed on a single LAN segment, there must be an
unambiguous means to assign IP addresses to all Balers. Configurations where more than one Baler may exist on a
LAN segment may include Q330's as well, which must handle IP address assignment to their associated Baler, or
may include no Q330's, such as in a playback center where multiple Balers are connected for simultaneous
playback.
• Recording tokens. The recording configuration, including principally what A/D channels are used to construct
MSEED channels of particular names, is stored in the Q330 as a series of tokens, which are read and interpreted by
the Baler when it opens a connection to the Q330.
• Well known UDP/IP Port numbers. The Baler may automatically issue a request to "switch servers" upon
listening for transmission attempts. A procedure must be followed to designate a specific UDP/IP port number for
Baler communication, in order to prevent the Baler from responding to packets not intended for it.
2.1.1.2 Implied Requirement: Continuity spanning power-up cycles & robust unattended
operation
• Continuity. The logical continuity of the recorded data must not be affected by the power-cycled mode of
operation. Typically internal data structures, such as those controlling data compression, require some "history."
Such history will be preserved automatically in the Baler in a continuity file (named TBD) written and maintained
by the Baler. The manner in which continuity is maintained should be robust so that the possibility of inadvertent
power down while writing it does not disable the Baler or corrupt the data stream. The best approach would be for
the Q330 to maintain a Baler-controlled continuity storage in an area of packet RAM. This avoids the need to
repeatedly re-write the continuity file, and permits continuous operation, in principle, even after exchanging Baler
hardware. Packet RAM is battery backed in the Q330.
• Baler "done." The Baler power is controlled by the Q330. Upon power-up, the Baler will begin data
acquisition (or recovery). When the Baler has completed a sequence of storing to disk a package of data delivered
by the Q330, the Baler informs the Q330 that the Baler power may be switched off.
• Static file allocation. The Baler is, by design, power-cycled frequently. Sudden loss of power in a remote
battery-powered environment is to be expected as a matter of course. Pathological power sources, for example
where a marginal solar power system provides adequate power during daylight hours only, are frequently
encountered in field operations. In addition, the "blind" nature of Baler operation, and the nature of field
deployment in general, imply that frequent detailed status examination of Baler performance by an operator, if there
is one, is unlikely. These considerations require a robust file allocation system that can't corrupt the disk structure,
lose data, or render the Baler inoperable as a result of inadvertent power-down. Static allocation of files once upon
Baler initialization, takes place under controlled circumstances, is likely to reduce the chance of file structure
corruption. All files used by the Baler in operation are allocated only once by a "Baler Configurator" application.
• Circular file allocation. The Baler will be expected to operate for long periods without operator attention.
One of the principle strong points of the SHEAR derivatives on previous Quanterra products is the "circular" mode
of operation of the internal disk data buffers that permit indefinite operation without "filling" the disk. In the
SHEAR-derivative systems, circularity is controlled by maintaining a "next-in" position within large contiguous
files. This requires somewhat more internal software management, and makes file-level recovery of recorded data
difficult, because the temporal starting point is not the start of the file. Circular operation can be achieved, however,
within the granularity of the size of each file by overwriting the oldest extant file. The Baler will incorporate the
ability to select either a circular or "linear" mode, i.e. recording will stop when the disk is full. This configuration
setting is stored in baler.ini.
2.1.1.3 Implied Requirement: Means to force flush pending data buffers to disk prior to
Baler switch
During some deployment modes, such as during scheduled controlled-source experiments, it may be desirable for an
operator to guarantee that the most recent data acquired by the Q330 is transmitted to and recorded by the Baler.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 7
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
There is a command in the Q330 to initiate manually a "buffer flush" operation. The Q330 may also be configured
to flush buffers automatically at periodic intervals.
2.1.1.4 Implied Requirement: "Attention" pushbutton
It may be desirable for an operator to terminate prematurely a disk write operation to prepare immediately for power
down of the Baler. There will be a push button on the Baler to terminate, or prevent for a brief period, such as 1
minute, a pending buffer write operation. This capability is provided to provide for a "clean" Baler swap. Baler
operation, however, will be such that in the worst case, only continuity would be lost if the Baler is swapped while
writing without requesting an "attention". Note that by designing the Baler software so that packets are
acknowledged to the Q330 only after they have been written to disk, there should be no packets left "in the air"
during an inadvertent Baler power-down. In no case should the Baler be rendered inoperable if powered down while
writing without having depressed the "attention" button.
2.1.1.4.1 Function of Interrupt Button: Concepts
There are three contexts in which the button can be used to initiate action:
1. Termination of a disk write in progress and prevention of a pending write. A brief, say 1s, press should be
sufficient to signal this. In effect, this is a general-purpose "exit". Some visual feedback in the LED pattern
indicating acknowledgement of the termination request is desirable. The termination request may be issued
while the Baler is actively writing; the context of the request is clear. A "prevent" request may actually be
issued while the Baler's CPU is powered down. Such a "prevent" must be distinguished from a "wake" request.
2. A "wake" request may be issued to the Baler when an operator comes on site so that data stored on the Baler
may be checked or recovered. A "double press", akin to a mouse "double click" might signal a "wake". When
manually woken, the Baler would remain awake for a predetermined configurable time, say 4hrs, or until the
"interrupt" button is pressed once as a "terminate" request.
3. There may be functions associated with configuration or IP address management that require that the Baler be
placed in a known state, or "learn" mode. A "learn" mode is used to establish an address link with a particular
Q330 that could be remembered after Baler power down. The “learn” mode is initiated by a long press, 5s, of
the "attention" button. The "Learn" mode has Red/Green toggling LED pattern, distinct from the normal
"active" LED. The learn mode is terminated by a single press of Attention button or software instruction.
2.1.2 Telemetry Application examples
The telemetry application examples suggest connections to specific logical ports. Some illumination of the strategy
may be helpful. Robust network design requires redundant central processing nodes and/or redundant routes to a
central processing node. Either of these, from the Q330 point of view, appear as a distinct destination IP address.
Routes are managed either statically or dynamically to reach each address and often diverge onto different circuits
to reach the destination. If the two central nodes can communicate with each other, then only one logical port is
actively delivering data, while the second is idle (Q330 receiving no acknowledgement). This conserves bandwidth
from the station and allows control to be exercised from the central node to activate either or both ports. The
telemetry queue affords some delay in exercising activation of a logical port because recent but duplicate packets
are in this queue. A similar strategy is used with MSHEAR comlinks.
The Q330 hotswap option, allowing any DP with a valid Q330 serial number and authorization code to immediately
take-over a logical port, can also be used to enable redundant central nodes. This is easier to configure on both ends
since ANY receiver can stand in for the central node and a logical port is freed on the Q330. Hostile or inadvertent
takeovers are possible with hotswap enabled on the Q330 logical port. The maverick packets cannot be recovered
by the designated central node except by data request mechanism, which is by MSEED channel. Patching a gap of a
few hundred telemetry packets may require 20 MSEED file segments.
The logical port designated as status messages is envisioned in two ways, for a local operator to receive SOH either
upon arrival or as a continuous monitor and second for a remote application to be able to monitor the SOH of the
entire network without itself being burdened with data collection and management. Large networks (>50 stations)
require automated monitoring for SOH.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 8
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
2.1.2.1 Application example: Serial Telemetry with Local Baler
In this example the Packet Baler is connected to the Q330 via Ethernet and acts as backup on-site recording. In this
case, a serial interface on the Q330 is used for telemetry.
logical 1: central hub 1
logical 4: Baler Storage
logical 2: central hub 2
Burst or Continuous TX
PB14 QNET Serial logical 3: status
Burst or Continuous TX
to status
to Central Hub 1
Serial port TE
to Central Hub 2
Q330 QNET Serial Console
FRAD, DSL,
ISDN, Radio,
VSAT, Dial
2.1.2.1.1 Implied Requirement: HTTP access to Q330 via Serial interface
The Q330's HTTP server should be accessible from either interface. Single-threading is adequate.
2.1.2.1.2 Implied Requirement: Means to communicate to all remote devices: IP switching & data
recovery
At remote sites, an Engine may have radio telemetry to a central facility on one interface and local connection to a
Baler on the Ethernet. It must be possible, for example, to inquire Baler status from the radio telemetry port, since
this is the only off-site communications in such cases. The need for this capability implies the requirement for "IP
switching" between ports. It may be desirable to treat "switched" packets with a lower priority than "primary"
outbound data packets associated with each port. The Baler implementation should permit recovery of recorded data
through the switched link, broadly similar in concept to the ability of MSHEAR systems to retrieve recorded data
while telemetering real-time data through an IP connection. Request-based data recovery in this type of deployment
might be used to "patch" an otherwise contiguous set of data that have been telemetered. The Q330 should route all
IP protocols. The only restriction on routed packets is the Q330's 576-byte MTU.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 9
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
2.1.2.2 Application example: LAN-based Telemetry with Local Recording
Ethernet connecting the Baler, Terminal Equipment and Q330 allows remote users to connect directly to the Baler
or Q330. Where power consumption is not critical, the Baler can be powered continuously, with the LAN connected
to NETA or NETB. The Baler's internal hub provides access to the Q330 directly from the LAN. The IP address
resolution protocol must guarantee that multiple Q330's and Baler's may be connected to the same LAN segment,
and that Baler IP address assignment is handled unambiguously. See later discussions of Address Management
2.4.2.
logical 1: central hub 1
logical 2: central hub 2
logical 3: status
NETA NETB logical 4: Baler Storage
Q330 QNET Serial Console PB14 QNET Serial Burst or Continuous TX
FRAD, DSL, to status
ISDN, Ethernet TE to Central Hub 1
Radio, to Central Hub 2
VSAT, Dial
2.1.2.3 Application example: Minimum-power continuous LAN access to Q330 with
power-cycled Baler
A variation on the configuration above allows continous LAN access to the Q330, and allows the Baler to be power-
cycled. The hub is not used for Q330 access. Bandwidth of serial Baler access is reduced, to perhaps several
hundred kbyte/min, still adequate for significant average power reduction in burst-mode recording.
Limitation: The Q330's Ethernet MTU is 576 bytes, which reduces throughput of packets switched from the Baler.
HUB
Power On/Off signalling
NETA NE TB NETA NETB
Q330 QNET Serial Console PB14 QNET Serial Q330 QNET Serial Console PB14 QNET Serial
BALER POWER CYCLING WITH SINGLE LAN DROP WITH HUBBED LAN DROP
2.1.2.4 Application example: Remote Digitization with Telemetry to WAN Access Site
This example shows a Q330 and sensor that are remote to the higher power devices like a Baler and Ethernet
terminal equipment. This type of deployment is useful to have the seismometer in a quiet location and the data
communication and recording in a convenient office. In this mode, the Baler must route packets to the serial
interface on which the Q330 resides. In this case, the Baler power supply is independent of the Q330.
Internet
Central Hub 1 Central Hub 2
Status Application
logical 1: central hub 1
logical 2: central hub 2 PB14 QNET Serial
logical 3: status logical 1: central hub 1
Burst or Continuous TX
logical 2: central hub 2
logical 3: status
logical 4: Baler Storage
Burst or Continuous TX
Q330 QNET Serial Console
2.1.2.4.1 Implied Requirement: Intelligent IP address assignment and retention
In this case, each time the Baler powers up, the Baler must use an IP address that is compatible with the Ethernet
LAN segment to which it's attached. The address may be suggested by the Q330, or may be configured in the Baler
prior to deployment. The Baler 14 may be deployed in a “wiped” mode, where the Q330 serial number is zero and
the IP address is set to a default value. When powered, the Baler will broadcast a request and a Q330 will suggest
an address, the Baler will accept the address and serial number of this Q330. If multiple Q330 are present on aPB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 10
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
network on which a “wiped” Baler presents itself the mating of 330 to Baler can be unpredictable. Ideally, already
paired Q330 would not respond to a Baler broadcast if their partner Baler is present. A means to uniquely associate
a particular Baler with a particular Q330 requires configuring that Q330 serial number into the Baler. That
association persists through an arbitrary number power cycles, and with Q330's and Baler's powering up in any
arbitrary order. See later discussion of Address Management 2.4.2.
2.2 Station-Level Interconnection
The Q330/PB14 will be most successful if users can easily configure them into a complete station. In many
applications, power distribution and cabling is handled ad hoc, resulting in inferior performance, and support
problems. We plan to provide connectivity in the Q330 and Baler to permit simple, uniform connections between
parts of a typical seismic station. Functional elements of a seismic station comprise:
• Q330 Data Engine
• PB14 Packet Baler
• SMU Station Management Unit, including power conversion from AC, battery charging, battery power input,
intelligent power monitoring, load switching, and (possibly) environmental monitoring.
• Some stations (with telemetry) have Terminal Equipment, including possibly a radio antenna.
• Batteries
• Sensor A
• Sensor B
• GPS Antenna
The cabling permits power distribution in the QNET cable and Sensor cable. The SMU provides CNP-compatible
control of the power/charging system that may be monitored by the CNP port of the Q330 (in the Power connector)
or of the Baler (in the Baler's Power connector).
Station Power/CNP Power/Signal Power/Signal
QNET
Management
Power/CNP Power/Signal
Unit Q330 Serial Console SENSOR
Power/Signal
SENSOR
Power/CNP
PB14 QNET Serial
Minimal-Cabling Station with Intelligent
Power Monitoring
Alternatively, the higher current draw of the Baler may be supplied through separate power cabling to the Baler
from the SMU, while the Q330 provides SMU power monitoring and control throught its CNP port.
Station Power/CNP Power/Signal
QNET
Management Power/CNP
Power/Signal
Unit Q330 Serial Console
Power
Power/CNP
PB14 QNET Serial
Direct Powering of Baler.
Power Monitoring by Q330
Similarly, the Baler may provide the primary control and monitoring, and supply power to the Q330.
Power/CNP QNET Power/Signal
Power/Signal
Q330 Serial Console
Station Power/CNP
Management Power/CNP
Unit PB14 QNET Serial Baler supplies power to Q330.
Power Power Monitoring by Baler’s CNP port.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 11
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
2.3 Baler functions
2.3.1 Modes of Operation
The PB14 operates in one of two basic modes of operation selected at power-up, based on the response to its
broadcast request for IP address assignment (the C2_BRDY) packet (if "Open" for assignment), or based on the
outcome of its attempt to register with it's associated Q330 data source, (if "Closed" for assignment, i.e. when it's
address is persistent).
1. Acquisition mode: data from the Q330 are acquired. The PB14 will simultaneously respond to requests for
data by time/MSEED channel or at a file level. Requests for serving data, however, will be handled at a
lower internal priority than data recording. Recovered data will be transmitted to the requester at a rate
controlled by a "throttle" parameter.
2. Vacuum mode: Transfer a specified list of channel rate/starttime/duration "windows" or entire files from
the Baler at maximum line rate. No Q330 is attached. This is the same as acquisition mode, except that the
"throttle" parameter is not used, and transfer occurs at maximum rate.
2.3.2 Levels of Baler Compliance.
There are 3 levels at which Baler operation can be "Baler Compliant":
1. Hardware: The pinout, levels, functions, and hardware and software protocols at every connector are
compliant with this Baler specification and the Baler 14 product. This is essentially a Baler 14.
2. Complete Software/Functional: The Baler interacts both with a Q330 data source, and a data requester in a
manner compliant with this specification, and the Baler 14. In addition, the Baler must comply with the IP
address assignment protocol. Strict adherence to "DP Token" usage in Q330 DP Token Definitions is required.
3. Retrieval Software Functional: A Baler may comply only with the manner of retrieving data, using HTTP
formatted requests. This allows disparate Balers to present a uniform interface to data users.
Interaction with the Q330 data source is defined by the Q330 protocol, and uses UDP/IP communications. The
Q330 protocol governs compatibility at this level. Requests of the Baler for data are formatted HTTP over TCP/IP.
At a minimum, a Baler must implement a sufficient amount of the HTTP request management to be able to identify
itself and its capabilities. A basic informative page, baler.htm, that identifies the type of Baler, and hence its
capabilities, and Level 3 (data retrieval access) are the minimum requirements for Baler compatibility. To
summarize, these areas comprise the major areas for Baler Compliance:
• HTTP request/response structure
• Configuration (ini) file management.What fields are in the file, and how they are established.
• File (data and configuration) access security
• Mechanism for IP address discovery and Baler mode selection, and Q330 protocol compliance.
• Unit identification and definition of capabilities.
The Q330 or Quanterra Domain Controller may status.htm
assign the Baler's IP address. The Q330's assignment
of a Baler address is visible through the status.htm
page at the Q330's address. This is used as the initial
link in finding a Baler. The "DP/Baler Information"
in the Q330 status.htm page points to the Baler's
baler.htm page. The address of a registered Baler is
also displayed if the Baler's IP address is statically
assigned, or the Baler is "Closed" for assignment.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 12
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
The Baler model and software version is found in the baler.htm
Baler's baler.htm page and can be used to select
software functionality in the requester to take
advantage of features implemented in the Baler.
2.3.3 Baler status
The following Baler status information should be made available through HTTP requests of the Baler.
1. data span by channel and free space on disk,
2. total power-on time,
3. number of power-ups,
4. time of last power-up,
5. report of timing
6. log of recorded data,
7. report of event log (if any),
8. message or error log containing entries for disk errors and
9. log of communications errors seen by the Baler and Q330 sides of the link between the Baler & 330.
10. If the Baler has any local CNP devices attached, such as power monitoring, it should be possible to inquire the
status of these devices in some manner via the connection to the Baler, and to set these parameters. Changing
settable parameters must be protected by password.
info.htm Communications link parameters may be viewed.
(Station name is "DEEP" in this example)
link.htmPB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 13
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
File access allows display and download of the recorded MSEED files. Maximum file size is settable. This
example shows maximum file sizes of 16Mbytes. The page must display the last file modification date. Some
means of deleting a rogue file, possibly corrupted in a failed transfer, might be required.
files.htm
Data may also be accessed in a time/channel request, much like MSHEAR. The HTTP request and associated
web page appears much like the MSHEAR retrieve.htm page.
retrieve.htm
2.3.4 Baler Power cycle control
In a minimum-power operational mode, the Baler is not powered most of the time. Two types of signal inputs to the
Baler are provided to request a power up of the Baler. These are the ENETBPWR pair and the DSR control line of
the data serial port, which would typically be driven ultimately by the DTR line of the host Q330 to which the Baler
is attached. The ENETBPWR pair is available in the QNET port. ENETBPWR in the Baler is a non-isolated
transistor switch input which is pulled up by the Baler and can be independently asserted by any device pulling
ENETBPWR+ down to ENETBPWR-, or circuit ground in the Baler. Normally the ENETBPWR isolated open-
collector output pair from the Q330 would be connected via the QNET connector to the Baler. The Q330 would use
this signal to power up and power off the Baler. The logical OR of the ENETBPWR and the DSR input is an input
request to the Power Controller, so that either means of signaling can be used. ENETBPWR is also separately
available on the control port of the Baler front panel. CNP commands via the X3 serial port on the power connector
of the Baler can also initiate a Baler power on. For power down, the Baler indicates to the Q330 that it is ready forPB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 14
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
a power down by sending a packet (C2_BOFF) that contains an interval to wait before power off to allow for
graceful shutdown. Following the wait interval, the Q330 drops the power control signal, which immediately
powers down the Baler. The ENETBPWR+/- pair is a wire-or'ed negative-true bus that may be asserted by any
requester. A requester is responsible to power-down the Baler at an appropriate time by deasserting the power
control signal. Note that using the Q330 to power-up the Baler on command requires registered access to the Q330.
An internal hardware jumper on DMU board allows forcing on Baler power.
2.3.4.1 Baler power up: implications for Q330 functions
There are several sources that may initiate a Baler power up:
1. Q330 asserts ENETBPWR to power up the Baler for a flush of its packet buffers.
2. An operator arrives on site and "wakes" the Baler, possibly using the Baler's "attention" button to recover data
or check on recorded data. An operator may also issue an explicit command to power up the Baler.
3. An offsite data user retrieves requested data.
For any remote access, the Q330 powers up the target Baler. Required approaches are:
1. The Baler may be powered by a specific Q330 command for a registered user which has inherent security.
2. There should be an HTTP-accessible, password-protected Q330 command to interogate the Baler. A user
who is not registered with the Q330 should have the ability to retrieve data from the Baler.
All remote power-up commands should be time-limited and have a means to prevent Baler power "thrashing."
2.4 Wholesale Q330 & Baler Parameter Setup and Data Recovery: QNET "seats"
Configuring and testing, let alone deploying, a large number of Q330's and Baler's present some particular
difficulties in IP address assignment and the consequent association of a particular Baler with a particular Q330. In
a realistic and practical "staging" environment, units come and go, are connected and disconnected in various states
of configuration or misconfiguration. To some extent, to reduce potential conflicts, a staging area with many units
may be partitioned into multiple separately switched LAN segments. And although some level of sobriety will need
to be maintained in what units are connected, as in the management of any IP network, the Q330 and Baler should
not present configuration and operation difficulties that are more confusing than other IP devices. In a typical
"staging" area, a potentially large number of Q330's and Balers may be connected by wired or possibly wireless
Ethernet LAN to a central "configurator" application program or "data vacuum" application. Multiple Balers may
be connected to a 100Mbit LAN through a 10/100 switch, to achieve high aggregate throughput in offloading
recorded data. Typical staging area topology might look something like:
Data Vacuuming Application
Configurator Application
Q330 QNET Serial Console
PB14 QNET Serial
HUB
Q330 QNET Serial Console
PB14 QNET Serial
Q330 QNET Serial Console
PB14 QNET Serial
In the staging area, a number of powered QNET "seats" might be wired, and labelled with IP addresses to which
units would be set when recovered from the field. Automatic "divination" of addresses and conflict resolution are
not required, but rational operation of a network with multiple Balers, Q330's, and application hosts is needed.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 15
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
2.4.1 Staging Area Activities
There are several classes of activity that might be carried out in a "staging area" on a network segment with many
Q330's and Balers before and after a large experimental deployment.
2.4.1.1 Q330 Configurator
A group of Q330's alone, or a group of Q330/Baler pairs, may be assembled prior to a deployment. Initially the IP
address of every Q330 is set, via the Q330's console port, Ethernet broadcast address, or IrDA port, to a subnet
reachable by the Configurator. A Configurator might:
• Initialize 330 to known state. Baler-specific configuration is managed by the Baler Configurator, which might
be the same as the Q330 Configurator application.
• Update or erase Q330 Flash modules to establish a version and revision level appropriate.
• Establish Baler operating modes and write "DP Tokens" defining the MSEED acquisition configuration.
• Input of recording parameters, (recording windows, startup times, warm-up time, sample rates)
• Check RTC setting (important for timed on-time experiments)
• Check GPS operation using re-radiating GPS antenna.
• Initiate a programmed sensor calibration on all units. This checks sensor, A/D operation, and timing.
• Test Q330 and Baler function by recovering cal data from the Baler
• Wait for deployment, while continually reporting status to the Configurator.
• Write a table of assigned values for import into data management databases.
2.4.1.2 Baler Configurator
There are a number of configuration issues specific to a Baler, i.e. that are NOT Baler independent. The issues
associated with the data recording configuration ARE Baler-independent, and are stored on the Q330 as DP Tokens.
Baler-dependent issues, managed by the Baler Configurator, include:
• Listen for Baler broadcast announcements, and suggest IP addresses. This is required before any more
advanced communications with the Baler.
• (optionally) Upload new operating code flash modules
• (optionally) Partition the disk in 2Gb chunks
• (optionally) Wipe disk of all existing files
• (optionally) Perform disk/CPU/serial diagnostics, including write/verify and loopback tests.
• Read-modify-write, or write and verify baler.ini file, containing special settings.
• (optionally) Set internal Real-Time Clock
• Pre-allocate files in specified sizes
• Associate a Baler with a specific Q330 serial number
2.4.1.3 Data Vacuum
Following recovery from a deployment, a Baler or number of Balers (simultaneously) may be polled to acquire
status, determine the associated Q330, and hence station, from which the data were acquired, and the data may be
off-loaded efficiently in file-level or time/SEED channel-level access. Such a "hoovering" of the data from the Baler
may be performed by a "Data Vacuum". The name is not intended to indicate an absence of data. Typical Data
Vacuum activities include:
• Listen for Baler broadcast announcements, and assign IP addresses according to some rational scheme
• Download all data and log files, by file or time/channel request using HTTP as fast as possible and with as little
user keystrokes or mouse clicking as possible, One is preferred.
• Write a table of channel contiguity over time per station
• Annunciate log or status conditions according to pre-determined severity/type mask. Examples of conditions
annunciated are:
o time loss or time quality degradation
o storage media errorsPB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 16
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
o data loss
o missing channels
o out-of-tolerance recorded state-of-health information, such as power-supply voltage
Data vacuum application should be able to confront a disk full situation on the host computer with some ability to
resume following appropriate operator actions to free space.
2.4.2 Implications for Address Management
The need to dynamically assign an IP address to each Baler - most of the time, i.e. except when you don't want to
change it - and statically to each Q330, requires creation of a rational address assignment scheme. Some of the
particular issues that must be handled include:
• Multiple assigners, e.g. Vacuum and Q330 on same LAN, require coordination. Reliance on simply a "retry"
mechanism results in first-come, first-served random assignment and Q330/Baler pairing. A possible
mechanism is for the Vaccuum to override the Q330 serial number assignment
• Address persistence. Important that a particular Baler retains its association with a Q330 to prevent the Q330's
data from being recorded by a random recipient - the winner of the "Baler survivor address assignment lottery".
On the flip side, the association must be possible to dissolve on request, using a simple procedure - perhaps
which involves the "attention" pushbutton. “Wiping” the Baler dissolves the Q330 serial number association
though it also deletes any data files. Separation of these two functions is probably not desired.
Sequence of address assignment in specific scenarios:
Q330 powers up an existing “mated” Baler.
“Wiped” Baler Swapped into a Q330/Baler pair.
“Full” Baler added to a network with Vaccuum Application running.
Q330 swapped into a Q330/Baler pair.
Swapping Balers into Multiple pairs on the same network segment.
2.4.2.1 Assignment on Serial and Ethernet Interfaces.
The means to provide "blind" swap and therefore automatic address assignment is needed only on the Baler
interface connected to the Q330, which is often the Ethernet, a multiple-access medium. The "open" and "close"
action is therefore context sensitive. If the Ethernet interface only is active, address assignment occurs on the
Ethernet when "open". If the Ethernet interface is inactive, address assignment occurs on the Serial SLIP interface
when active. When the Ethernet and SLIP interfaces are active, the Q330 may assign addresses for both interfaces.
If assignment is requested, but no assignment is made on a given interface, the address is not changed.PB14 Baler Design Overview - Revision 1_pub - 7:14 PM 03/24/03 - Page 17
CONTAINS PROPRIETARY INFORMATION. UNAUTHORIZED DISCLOSURE IS PROHIBITED.
DO NOT PHOTOCOPY OR REPRODUCE WITHOUT WRITTEN PERMISSION
END OF DOCUMENTYou can also read
