source: trunk/ewdoc/WEB_DOC/ovr/tankplayer_ovr.html @ 2166

Revision 2166, 3.4 KB checked in by withers, 14 years ago (diff)

Updated to v7

  • Property svn:eol-style set to native
  • Property svn:keywords set to Author Date Id Revision
Line 
1
2<HTML>
3<HEAD>
4<TITLE>Earthworm Modules: Tankplayer overview</TITLE>
5</HEAD>
6<CENTER><H1>Tankplayer Overview</H1>
7<I>(last revised 19 May 2006)</I></CENTER>
8
9<P>
10"tankplayer" is part of the four-program set for recording and playing back the trace data for selected time intervals. See also <A HREF="trig2disk_ovr.html">trig2disk</A>, <A HREF="waveman2disk_ovr.html">waveman2disk</A>, and <A HREF="wave_serverV_ovr.html">wave_serverV</A>.
11<P>
12Tankplayer has two common uses:
13<P>
14Tuning Operating Earthworms:
15<P>
16For example, an Earthworm system fails to locate a significant earthquake.  The waveform data for the earthquake is requested from the wave_server and saved in tankplayer format.  Using an experimental Earthworm, the event is played back with tankplayer, tuning the operational parameters until Earthworm performs satisfactorally.  The operational parameters are then changed to those used in the test.
17<P>
18Quality Assurance:
19<P>
20One is to perform quality assurance tests. For such tests, an experimental Earthworm system would be set up, and one or more tankplayers would be connected as the data source. Each tankplayer would be given a lengthy list of data files, and "tankplayer" would play (broadcast into the earthworm) the trace data from these files, one after another, generally overnight. The earthworm system under test would then process the incoming data. In the morning, we would come in and examine the rubble.
21<P> 
22Menlo Park has created a collection of over 50 historic trace data files, representing the trace data traffic during various 'moments of horror' at CalNet. These include the Loma Prieta mainshock, swarms during wind storms, concurrent events in different parts of the net, events during telemetry malfunctions, etc. These files were painfully created by reformatting CUSP data archive files. The format of these files is simple: it is a series of messages of TYPE_ADBUF, written with a binary write.
23<P>
24How Tankplayer Works:
25<P>
26On startup, tankplayer reads its configuration file. This specifies the message ring into which to inject the data, and the module name to use. Tankplayer is generally told to imitate a real data source, such as an A/D module, or a digital acquisition module. The parameter file also lists the data files to be played back. It also specifies a pause period. This was implemented to prevent the earthworm associator (binder) from becoming confused by rapid jumps in time between data files. This time period should be set to be larger than binder's association memory, to prevent it from trying to associate phase arrivals from different data files.
27<P>
28In operation, tankplayer places the waveform messages from its input file(S) into shared memory in simulated real time, using the delta-t between time-stamps in successive message headers to determine its timing. When the end of file is reached, it waits "Pause" number of seconds, and goes on to the next file, as specified in the parameter file.
29</P>
30<P>
31Tankplayer is location code compliant and backward compatible.  It accepts
32messages of either tracebuf or tracebuf2 as configured using the PlayMsgType
33parameter.
34</P>
35
36<CENTER> 
37<A HREF="../modules.html">Module Index</A> |
38<A HREF="../cmd/tankplayer_cmd.html">Tankplayer Commands</A>
39</CENTER>
40
41<HR>
42<ADDRESS>
43The URL of this page is  <B>[http://gldbrick.cr.usgs.gov/ew-doc/ovr/tankplayer_ovr.html]</B><BR>
44Contact: <B>dietz@usgs.gov</B><BR>
45</ADDRESS>
46</BODY>
47</HTML>
48
Note: See TracBrowser for help on using the repository browser.