FAQS
PASSCAL Frequently Asked Questions DAS \ Sensors \ Multi-channel System Field Computers \ Data Processing \ Database & SEED \ Other The following list of questions and answers is meant help users find information on topicsthat others have found difficult or unclear. The topics are broadly subdivided by subject tomake locating a specific question easier. Section 4.1 DAS
4.1.1 How do I repair bad blocks on a REF TEK disk? 4.1.2 Which channels are 24 bit on the A-08?
4.1.3 How hard is it to upgrade the DAS firmware/software in the field?
4.1.4 The GPS clock does not seem to power cycle correctly, sometimes
staying on for a long time, what's wrong? 4.1.5 The DAS status reports
4.1.6 What is the fastest sample rate I can record three channels?
4.1.7 Can I record more than one channel per stream?
4.1.8 The DAS fails to automatically dump data to disk.
4.1.9 It seems every other (or every n ) TIM window is being recorded.
4.1.10 What are the trigger parameters you suggest for RAMP deployments?
4.1.11 How do I charge the internal battery of a 72A series DAS?
4.1.12 Why do I no longer see the
message NO UTC CLOCK in the DAS STATUS Window even if the receiver
power has been cycled off to
conserve power?
Section 4.2 Sensors
4.2.1 What is the characteristic difference
between tilt induced signal and
other noise sources?
4.2.2 (a) Which way is north on the L-22?
(b) Which way does the rod point for STS-2?
4.2.3 What if the hole we dug for the
STS-2 is too small to see the
bubble or get the rod in the side?
4.2.4 The cables are not long enough
to reach from the sensor vault
to the DAS, can we get longer cables?
4.2.5 What if the sensor pad is
sloped too much and the levelling
feet can't get the seismometer level?
4.2.6 One element of the Guralp seismometer
does not seem to center, it is
a) stuck in the same position
or b) gets close to centered
and then drifts away when the
centering process quits.
4.2.7 What voltages are appropriate
for calibrating the broad-band and intermediate-band
sensors via the DAS?
Section 4.3 Multi-Channel System
Section 4.4 Field Computers
4.4.1 The tape I brought to the field cannot be read by the field computer.
Section 4.5 Data Processing
4.5.1 The PASSCAL software did not compile properly.
4.5.2 The files do not seem to start
all at the same time, though
TIM trigger was set.
4.5.3 The pre-event memory seems longer than specified, and varies in length.
4.5.4 Is it possible to time align data samples from different DAS?
4.5.5 Some of the EVT triggered
data seems to overlap a previous
event. Is this possible?
4.5.6 The recorded signal appears
clipped on some datastreams
but not on others. How can I tell if the signal is clipped?
4.5.7 The station disk has data
but the Sun can't see it,
and the DAS can. What gives?
4.5.8 The gain was incorrectly entered
on the field terminal, how can
I correct the data?
4.5.9 How do I correct the data time labels for clock adjustments?
4.5.10 Can I disconnect a disk
if ref2segy or any other
program accessing a RefTek disk is running?
4.5.11 What format is the field DAT RefTek tape written in?
4.5.12 How do I deal with a
RefTek disk that gives the
warning message: WARNING! NO REFTEK LABEL. DO NOT CLEAR IF
NOT A REFTEK DISK!?
4.5.13 When I refdump my RefTek/FCS
to a disk file I only get
2Gb of data, yet I know that
there is more than 2Gb on
disk. At first I thought
there were block errors on
the disk, but there were no system errors in my Console window.
I've also tried to create disk images using dd but have not been
successful. Why?
Section 4.6 Database & SEED
4.6.1 I just discovered that one of my sensors
is reversed. How do I correct thisfor all the data I've attached?4.6.2
My pdbload/tkpdbload process dies with the following errors: PDBLOADdied
with error: child killed: write on pipe with no readers4.6.3 podgen
reports a strange error message from qmerge unable to open:/usr/local/lib/leapseconds.
What do I do about this?
4.6.4 When I run podgen, I get 2 error messages:
env. var. JSPDB not set; JSPC prog. unavailable in setup autopath open file /opt/local/pgsql/.podgendefaults failed; continuing
Are these cause for concern?
Section 4.7 Other
4.7.1 The
EHT does not work; the screen is blank.
4.7.2 One of our [recorders, sensors, or computer devices] has failed. Should we
send it back to the manufacturer?
4.7.3 We want to make our own cables, where do we get connectors?
4.7.4 We want to [start earlier
/ stop later] than the schedule
says, is that a problem?
Section 4.1 DAS
4.1.1 How do I repair bad blocks on a REF TEK disk?
If you encounter error messages of the type:
WARNING: /sbus@1f,0/esp@0,200000/sd@1,0 (sd16):
Error for Command: read(10) Error Level: Retryable
Requested Block: 16896 Error Block: 17091
Vendor: SEAGATE Serial Number: JKB31256
Sense Key: Media Error
you can identify and repair bad blocks on the REF TEK disk by running the Solaris format
command. NOTE: This approach does not always work and may result in lost
data if not done carefully!
To locate and repair bad blocks, call format:
% format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. sd5 at esp1 slave 8
sd5: <IBM DALS-3540 cyl 3911 alt 2 hd 2 sec 135>
Specify disk (enter its number): 0
selecting sd5: <IBM DALS-3540>
[disk formatted, no defect list found]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
show - translate a disk address
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
quit
If your operating system is Solaris, the bad block number will appear in your console
window. Note this number.
Select analyze from the FORMAT MENU, followed by test. Format will pattern test
each block and repair them as needed.
(updated 11/2/99)
4.1.2 Which channels are 24 bit on the A-08?
The 24 bit channels are 4,5,& 6 (the rightmost input plug). The
choice of gain FOR THESE
CHANNELS is either 1 or 32. Channels
1,2,& 3 (the leftmost input plug) are 16 bit, with
programmable gain options
(submitted 2/9/99)
4.1.3 How hard is it to upgrade the DAS firmware/software in the field?
New EPROMS must be installed in the CPU board, and possibly the DSP board. The DAS must
be opened, the card cage removed, the particular card removed and two chips pried out and replaced
with new ones and the whole thing put back together again. An experienced technician can do this
in a lab in 40 minutes with about 95% of the DAS working on powerup. In the bush, the rate could
drop to 85% and take a little longer. A novice would take twice as long and the odds of it working
are lower still. Further consideration should also be given to the dismantling of the station just to
get the DAS free from all the interconnecting cables and correctly reconnecting them. As a rule,
PASSCAL does not upgrade DAS software during an experiment but has been forced to when
bugs have appeared after equipment was shipped. The next best option is to return units to a
suitable environment such as the field headquarters and upgrade several units as a group. This
allows a certain amount of cross-checking and group testing.
(submitted 2/10/99)
4.1.4 The GPS clock does not seem to power cycle correctly, sometimes staying on for a long time, what's wrong?
V2.22 of the GPS clock software includes a bug whereby if the clock locks to only a single
satellite, it never turns off. The situation may be improved by increasing the clock's view of the sky
so as to allow it to lock to more than one satellite. The software will be replaced as available. All of
the GPS clocks should now have V3.X or higher in which this particular bug is not a problem.
(submitted 2/10/99)
4.1.5 The DAS status reports
(submitted 2/10/99)
4.1.6 What is the fastest sample rate I can record three channels?
Depends. If using a single stream, recording to RAM, then all DAS can record the maximum rate
of 1000 sps, except the A-06 which can only do 500 sps. If autodumping to SCSI, i.e. OP MODE
SC, then the maximum rate for all DAS is 500 sps due to the RAM filling before the autodump has
completed. Multiple streams, as a rough guide, are limited to the maximum rate above divided by
the number of active streams. Exceeding a throughput of 1500 sps (total number of sps for all
streams, all channels) is not advised.
(submitted 2/10/99)
4.1.7 Can I record more than one channel per stream?
You can record any combination of active channels on each stream. See the example parameters
sets for ideas. Note that the channels must be active before they will be properly recorded.
(submitted 2/10/99)
4.1.8 The DAS fails to automatically dump data to disk.
The most likely cause of this problem is the station power is not sufficient to spin the disk, in which
case the disk controller will refuse to operate and the DAS will record a SCSI ERROR 9202. Other
likely possibilities are loose or damaged SCSI cable between the DAS and Disk, or a loose or
damaged cable within either the DAS or the disk. See also Field Note Troubleshooting DAS.
(submitted 2/10/99)
4.1.9 It seems every other (or every n ) TIM window is being recorded.
The interval is shorter than, or equal to, the record length. The interval is the time between the start
of one window and the start of another window, not the time between the end of the first window
and the start of the second window. The DAS records a datastream when triggered and ignores all
subsequent triggers until the event expires. In the case above, the DAS misses every other window
because the second start time falls within the first recording window. The interval must be at least
one second longer than the record length for things to work.
(submitted 2/10/99)
4.1.10 What are the trigger parameters you suggest for RAMP deployments?
Typical RAMP trigger parameters for local events:
--> Stream 1 (SP Seismometer) Trigger Parameters:
trig chls=xyz
min chls=1
trig wind=1
pretr len=30
posttrg len=60
recrd len=50
sta lngth=0.5
lta lngth=30
mean rmvl=(leave blank)
trig rat=4.5
detrg rat=3.5
LTA hold=(off)
(submitted 2/10/99)
4.1.11 How do I charge the internal battery of a 72A series DAS?
CPU Battery:
The CPU board has a 2.4 volt back-up battery to retain CPU RAM when the DAS is powered off
or asleep. This battery also powers the Perpetual Time Clock of the CPU under those same
conditions. When external DAS power is available and the DAS is turned on, this battery is
recharged via the 5 volt Vcc. The Vcc voltage is constantly monitored. If Vcc falls below 2 volts the
monitor chip switches RAM and PTC circuits over to operate from the back-up battery.
If ever the back-up voltage becomes very low, the contents of CPU RAM are lost and the DAS
reverts to sleep mode with acquisition set to 'STOP-OFF'. The initial indication of a low back-up
voltage is that DAS time becomes erratic and eventually defaults to 1988:001:00:00:00:000 - this
occurs at about 0.4 volts. RAM content and timing accuracy are guaranteed to remain intact as long
as the back-up is 2.0 volts or more. Experiments have shown that the RAM can remain intact down
to 0.3 volts, but this is not guaranteed.
These problems can be avoided if the back-up battery is kept charged. Although the back-up battery
will keep critical circuits powered for several weeks it is advisable to charge it before DAS
deployment, particularly if the DAS has been out of service for a while. A fully charged battery can
theoretically give approximately 180 days of service. A drained battery requires 72 hours to reach
full charge from a >12 volt source attached to the DAS Power connector
(the DAS MUST be
powered up in continuous mode).
(submitted 2/31/99)
4.1.12 Why do I no longer see the message NO UTC CLOCK in the DAS STATUS
Window even if the receiver power has been cycled off to conserve power?
This difference is related to GPS firmware upgrades in the DAS. In the past, the DAS displayed the
following messages
Message
Meaning
NO UTC CLOCK
GPS not powered
UTC ULK PLU
GPS powered, unlocked
UTC LK PLL
GPS powered, locked
but here are the new status messages and their interpretations:
Message
Meaning
UTC ULK PLN
GPS not powered and/or not locked to satellites
DAS not phase locked to GPS
UTC LK PLU
GPS locked to satellites
DAS not phase locked to GPS
UTC LK PLL
GPS locked to satellites
DAS phase locked to GPS
(submitted 7/13/99)
Section 4.2 Sensor
4.2.1 What is the characteristic difference between tilt induced signal and other noise
sources?
Tilt signals appear predominately
on the horizontal channels, most often with the tilt vector varying
in both direction and magnitude.
A consistent direction may indicate an identifiable source of tilt,
such as a loose leveling foot,
unstable pad, tree nearby, etc. Secondary tilt effects may be observed
due to thermal expansion of the
immediate environs, particularly in late afternoon. By low-pass
filtering the vertical channel
(say, 4 poles at 0.033 Hz.) you may be able to correlate signals
on the
vertical channel with the much
higher amplitude signals on the horizontals. Sensor pings, a sudden
step in acceleration, are usually
observed on a single channel (or element in the case of STS-2 with
corresponding outputs scaled
by the rotation matrix). Site disturbances by animals, including
humans, often show vertical signals
corresponding to footsteps and then wild tilting on the
horizontals.
(submitted 2/10/99)
4.2.2 (a) Which way is north on the L-22?
(b) Which way does the rod point
for STS-2?
The sensor flashcards in the
sensor section of the manual have a diagram to explain this. But,
the
answers are:
(a) the arrows point north and
east, that means it can sit only one way, and
(b) east.
(submitted 2/10/99)
4.2.3 What if the hole we dug for the STS-2 is too small to see the bubble or get the rod in the side?
Try using the mirror on your
Brunton compass to see the bubble, note the levelling is complicated
by the reverse image. Or use
a stubby orienting rod (a three inch pointed version of the rod)
and
align this and the U element
foot with a line marked as east on the pad.
(submitted 2/10/99)
4.2.4 The cables are not long enough to reach from the sensor vault to the DAS, can we get
longer cables?
It is possible to make longer
cables for some sensors, particularly the 1 Hz. sensors,
but PASSCAL
does not supply them. Longer
cables for BB sensors are limited to around 10 m
and are easier to
add between the breakout
box and DAS rather than between the breakout box
and sensor. Again
PASSCAL does not supply them.
Custom cable making is a serious drain on PIC resources,
perhaps after you make one
or two you'll see why.
(submitted 2/10/99)
4.2.5 What if the sensor pad is sloped too much and the levelling feet can't get the
seismometer level?
Use some coins under the
feet to prop it up. This solution is limited to 3-4
coins before the stack
becomes unstable. Every effort
should be made to construct the sensor pads with
a level surface,
and this is simply a trick
to overcome an earlier bungle.
(submitted 2/10/99)
4.2.6 One element of the Guralp seismometer does not seem to center, it is a) stuck in the
same position or b) gets close to centered and then drifts away when the centering process
quits.
a) The sensor may indeed
be stuck, try locking and unlocking it a couple times. If it
is still stuck
you may need to whack it.
Please read the Guralp installation Field Note for more specific
clues as
to the problem and possible
remedy.
b) The sensor probably has
a damaged pivot for which there is no field remedy. Contact the
PIC
for a replacement.
(submitted 2/10/99)
4.2.7 What voltages are appropriate for calibrating the broad-band and
intermediate-band sensors via the DAS?
When programming the DAS
for calibration, we use the following amplitudes for the calibration
coil outputs:
STS-2 8.0 Volts
CMG 3T 0.1 Volt
CMG 3ESP 0.1 Volt
CMG 40T 0.25 Volts
(submitted 2/10/99)
Section 4.3 Multi-Channel System
Section 4.4 Field Computers
4.4.1 The tape I brought to the field cannot be read by the field computer.
PASSCAL computers support
only noncompressing tape devices.
Any tape written by a
compressing drive, whether
DAT or Exabyte, cannot be read
by the field computer's tape drive.
Most compressing drives allow
a tape to be written in noncompressing
format by specifying a
different device driver.
Still, before relying on the
tape, try to read it with a PASSCAL type drive.
This device incompatibility
is why PASSCAL does not use these
drives.
(submitted 2/10/99)
Section 4.5 Data Processing 4.5.1 The PASSCAL software did not compile properly.
We now suggest that users
install one of our pre-compiled
packages. These are currently
available
as both Solaris packages
and for Linux as RedHat RPMs.
If you must build the release
from the source code, first see
Installing the PASSCAL Source
Code
from Appendinx C of the Database
Training Manual. PASSCAL Software
uses shared libraries
and header files. The paths
to these libraries are most often
the problem when compiling a
program
separately from the whole
bundle. There have been a few
instances of newly released software
referencing files which exist
only at the beta site at the
PIC. Usually a patch for a distribution
is
subsequently released. Contact
the PIC and include the exact
error message for further assistance.
(submitted 2/11/99)
4.5.2 The files do not seem to start all at the same time, though TIM trigger was set.
The REF TEK recording system
is based on packetized data.
When a specific time or amount
of
data is requested, the DAS
rounds the requested amount up
to the nearest whole packet boundary.
Uncompressed data packets
contain 1000 bytes of a single
channel for each datastream.
Compressed data packets vary
in the time interval and number
of samples contained.
The requested data is always
included, and the remainder of
that packet as well.
(submitted 2/11/99)
4.5.3 The pre-event memory seems longer than specified, and varies in length.
The REF TEK recording system
is based on packetized data.
When a specific time or amount
of
data is requested, the DAS
rounds the requested amount up
to the nearest whole packet boundary.
Uncompressed data packets
contain 1000 bytes of a single
channel for each datastream.
Compressed data packets vary
in the time interval and number
of samples contained.
The requested data is always
included, and the remainder of
that packet as well.
(submitted 2/11/99)
4.5.4 Is it possible to time align data samples from different DAS?
The data sample is accurately
tagged (usually), but is not
aligned with any arbitrary boundary
(on
the second for example).
To align data from different
DAS, not just plot them on the
same absolute
time scale, the data must
be resampled, interpolating datapoints
at a chosen time between the
actual
samples. The broad bandwidth
of recorded data (80% nyquist)
means that cubic spline
interpolation methods are
often inadequate and more robust
techniques (e.g., (sine x)/x
deconvolution) should be
used. This is a computationally
extensive job and not usually
necessary.
Phases can be accurately
picked from any trace. In refraction
work, the sample closest to the
second
boundary is chosen as the
starting point with the offset
included as a static.
(submitted 2/11/99)
4.5.5 Some of the EVT triggered data seems to overlap a previous event. Is this possible?
The DAS can assign the same
packet of data to two or more
events as the parameters warrant.
In
this case the preevent time
from the second event includes
packets which are part of the
record
length of the first event.
To merge these separate events
into a single trace, use the
segymerge
program with the -o option.
The program checks the seam by
comparing 10 adjacent samples
from
each file before merging
the two files into one.
(submitted 2/11/99)
4.5.6 The recorded signal appears clipped on some datastreams but not on others. How
can I tell if the signal is clipped?
It is impossible to determine
whether the input signal to the
DAS exceeded the A/D conversion
range on any particular sample.
Because all DAS use some form
of oversampling, the raw samples
may contain some clipped
values which when averaged with
other raw samples to form an
output
data sample does not result
in an overall clipped value.
The oversampling software should
simply
clip the output when any
input value is clipped. The fact
that some streams show clipped
output and
not others is governed by
the amount of averaging required
for the specified sampling rate.
Lower
sampling rates use more averaging
and are less likely to appear
clipped, but are still distorted.
Recorded signals greater
than 90% full scale should be
treated warily.
(submitted 2/11/99)
4.5.7 The station disk has data but the Sun can't see it, and the DAS can. What gives?
For disks to be used with
REF TEK DAS and Sun OS, each
system writes a label on the
disk. The
Sun label is stored on sectors
0 and 1. The RefTek label is
stored on sectors 2 and 3. You
can add
the Sun label at any time
using the program format and
specifying the disk type. PASSCAL
includes a list of types
for all PASSCAL disks on its
computers or this file may be
obtained via
email or ftp from the PIC.
See the Field Note on labeling
disks.
Another possibility may be
that under Solaris the OS can
be told to probe for disk devices
at boot
time. If the OS does not
see the device at boot time,
as for as the OS is concerned,
the device does
not exist. If a disk is added
to the system, and the OS is
never told to search for devices
at boot
time, the OS won't ever see
the disk. Try rebooting/booting
with the
(submitted 2/11/99)
4.5.8 The gain was incorrectly entered on the field terminal, how can I correct the data?
The values for any SEGY header
variable can be listed with the
program segyhdr. The header
values can be altered with
the program segymod. Several
hundred files can be modified
in a minute
using wildcards.
For MSEED files, there is
no scale factor in the header.
For both SEGY and MSEED,
you will want to correct the
database. This is done most easily
with
pdbedit, fixing the preamp
gain in the channel table. Database
entry tables (Reftabs) can be
edited prior to loading them
in the database. It may be prudent
to edit the logfile and include
a
comment (via podgen) as to
what has happened.
(submitted 2/11/99)
4.5.9 How do I correct the data time labels for clock adjustments?
Please see the Field Note
on Clock corrections. The topic
is complicated and automatic
correcting
software cannot handle every
possible case.
However, most cases are handled
correctly by pdbrate. If you
are concerned that the time
corrections are not being
applied correctly, please send
the log and pcf files to
passcal@passcal.nmt.edu.
A fax/plot/screen shot of the
clockview display would also
be helpful.
(submitted 2/11/99)
4.5.10 Can I disconnect a disk if ref2segy or any other program accessing a RefTek disk is
running?
We have encountered some
problems with the SCSI transfers
from the Reftek disks to the
Sun. If
you run into a problem with
ref2segy or any other program
that is accessing the Reftek
disk, be
sure that all programs accessing
the disk are terminated before
disconnecting the disk. NEVER
disconnect the disk in the
middle of a transfer.
(submitted 2/11/99)
4.5.11 What format is the field DAT RefTek tape written in?
The field DAT tapes written
by the RefTek have 3 files on
them. The first two are 1024
byte files
that simulate the Sun and
Reftek Disk labels. The third
file contains the RefTek packets
blocked
out at 1024 bytes. It is
necessary to use the -t option
to access this data using the
PASSCAL
programs ref2segy, ref2tab,
refpacket, or ref2log. The -t
option will skip the first two
files on the
tape and read the data from
the third.
(submitted 2/11/99)
4.5.12 How do I deal with a RefTek disk that gives the warning message: WARNING! NO
REFTEK LABEL. DO NOT CLEAR IF NOT A REFTEK DISK!?
This disk has lost it's RefTek
disk label that sits at sectors
2 and 3. First read the manual
page for
diskclear. The diskclear
utility writes a new RefTek label
on the disk however the start
sector is
zeroed (or set to sector
4). To reset the start sector
to the amount of data that is
actually on the disk,
use the diskclear -a option
and specify the number of SECTORS
when prompted. The SCSI STAT
screen on the DAS provides
the number of kilobytes used,
so multiply this number by 2
to
determine the number of sectors
(a sector is 512 bytes).
(submitted 2/11/99)
4.5.13 When I refdump my RefTek/FCS to a disk file I only get 2Gb of data, yet I know that there is more than 2Gb on disk. At first I thought there were block errors on the disk, but there were no system errors in my Console window. I've also tried to create disk images using dd but have not been successful. Why?
Versions of Solaris prior
to Solaris 2.6 are not large-file
aware. This means that unless
you
upgrade to Solaris >= 2.6, you are limited to disk files no larger than 2Gb. Your >2Gb
RefTek/FCS
disk can only be dumped directly
to tape with older versions of
Solaris.
Whether your are dumping to tape
or disk, you may also have trouble
with older versions of the
PASSCAL refdump program (and
dd). In this case, you must use
the raw device name (e.g.
/dev/rsd5c or /dev/rdsk/c1t1d0s2)
instead of the blocked device
(e.g. /dev/sd5c or
/dev/dsk/c1t1d0s2) to address
the RefTek/FCS. Upgrading to
PASSCAL release1.9.20 will solve
this problem; as of PASSCAL release
1.9.20 refdump uses raw device
names as defaults.
(submitted 4/28/99)
Section 4.6 Database & SEED
4.6.1 I just discovered that one of my sensors is reversed. How do I correct this for all the
data I've attached?
If the sensor is reversed for
the whole deployment, DO A MANUAL
OVERRIDE:
1.simply edit the NC file to
reflect this for all entries,
2.sort the NC files by SITE name,
3.set the rules, and turn off
rules #19 & #20, choose Apply,
4.select all the NC entries for
this site,
5.click on TEST ENTRIES, and
6.click on PEFORM ATTACH
the above will fix the orientations
only for this one sensor.
(submitted 2/10/99)
4.6.2 My pdbload/tkpdbload process dies with the following errors:
PDBLOAD died with error: child
killed: write on pipe with no
readers
This usually indicates a problem
with the PostgreSQL database.
Check to see that there is enough
space in the directory where
it is stored and that the postmaster
process is running. If these
check
out, try vacuuming the database
before attempting to load the
file again. Occasionally, the
reftabs
can be bad because a new RefTek
idiosyncracy has appeared. Contact
passcal at our mail alias and,
as always, give lots of details.
(submitted 2/11/99)
4.6.3 podgen reports a strange error message from qmerge
unable to open: /usr/local/lib/leapseconds
What do I do about this?
Qmerge is used to dealing with
data that may have leapseconds
introduced and uses this file
to deal
with it. You may safely ignore
this warning since the RefTek
handles leap seconds internally.
(submitted 2/13/99)
4.6.4 When I run podgen, I get 2 error messages:
env. var. JSPDB not set; JSPC prog. unavailable in setup
autopath
open file /opt/local/pgsql/.podgendefaults failed; continuing
Are these cause for concern?
You only need the JSPDB environment
variable set if you want to run
datascope or use podgen to
convert data to CSS format; it
is a warning and not an error.
The .podgendefaults means that
under the Options menu item you
have never hit the Write
Defaults File button, so you
are just using the podgen-defined
defaults.
(submitted 2/15/99)
Section 4.7 Other
4.7.1 The EHT does not work; the screen is blank.
The EHT has a powersaving feature
that blanks the screen if inactive
for 2 minutes. Turning the
power switch off and on again
will cause the terminal to
resume without interruption. After
shipping, the EHT batteries
are often discharged and the terminal
must be recharged overnight
before the terminal will work
properly. When charged, it
may be necessary to reset the terminal
by
pushing the reset button on
the side. Follow the instructions
in the Field Note.
(submitted 2/10/99)
4.7.2 One of our [recorders, sensors, or computer
devices] has failed. Should we send it
back to the manufacturer?
No, send all malfunctioning
hardware back to the PIC. The PIC will
test the unit to confirm the
problem and fix it if possible.
The PIC has various service
agreements with different manufacturers
and we ask you do not interfere
in this relationship. Further,
the PIC catalogs the history
of
problems in order to develop
preventive practices or make
revisions.
(submitted 2/10/99)
4.7.3 We want to make our own cables, where do we get connectors?
See the vendors list for vendors
PASSCAL has used. Be sure to
get the correct part number
from
the manuals or from an existing
part in hand.
(submitted 2/10/99)
4.7.4 We want to [start earlier / stop later] than the schedule says, is that a problem?
Yes usually. The schedule of
equipment as distributed by
IRIS HQ is modified slightly by the
PIC
Experiment Coordinator to fit
the PIC and experiment schedules,
including adjustments for
hardware upgrade or maintenance.
There may be some flexibility
but more often not due to the
number of competing factors
for instrument time, including maintenance.
The dates set forth are for
equipment departing from and
returning to the PIC, they
do not include transit time to and
from the
experiment area by whatever
method. More time can sometimes be gained
at the expense of more
rapid shipping methods.
(submitted 2/10/99) |
