All,

I made a few changes to the format (see
http://www.seismicnet.com/psn4tbl.html) based on the comments from Edward.
All floats have been changed to doubles and I changed some bytes and shorts
to longs. The variable length section can now have data fields larger then
255 bytes.

At 06:01 PM 6/29/00 -0600, Edward wrote:

>With respect to the "DateTime Structure", I would suggest that since you are
>using a "long" to store the fraction of seconds, you might as well store
>nanoseconds. I mean, if you got, i.e., the precision, why not flaunt it? 

I renamed the field to nanoseconds.

>you
>never know when you'll need it. Also, it would be useful to include a clock
>correction in seconds as a double (type/length) that could be added to the
>nominal time that the samples were originally time-stamped with when
recorded.
>Particularly in the case of "unlocked" data, that estimate of true time
might be
>fuzzy and controversial.

It seems to me that the start time should already include this information.
Basically the start time of the first sample is based on the best
information the data logger has at the time it saves the data to disk.

>
>> The next sections is the seismogram data. The data array can be either 16
>> bit integer, 32 bit integer or floating point. After the data is two CRC-16
>> bytes. This is used to verify the integrity of the headers and data
sections.
>
>Do you mean dis dat or dat one? When referring to the discrete values of the
>recorded seismic timeseries, I always try to use the word "samples" rather
than
>"data" to distinguish them from the other data, such as time-stamps,
instrument
>constants, or station info.

I changed some of the places where I used the word data to samples.

>Two thoughts:
>
>1) To avoid worrying about the different "Type/Length" of parameters, all
>parameters -- other than the "Variable Length" info -- could be stored in the
>form of the most inclusive type: 8-byte double floats. Though this will waste
>some space -- which will be small compared to the data-mass of the samples
-- its
>uniformity will be easier to program and it will accomodate future
upgrades of
>parameter precision.

Done.

>
>2) As I said in a presentation at the IRIS workshop in 1983 that was held to
>launch the PASSCAL Program: "seismic data is like nuclear waste: both need
to be
>stored in dumps while awaiting processing", and we need a "Cosmic
Database" to
>store all these data and make them rapidly accessible to all. Got any
ideas about
>putting it all together, such that all the header info of all event/volume
files
>can be rapidly queried and the corresponding waveform samples can be
retrieved
>via the Web?

One step at a time.....Any database programmers out there?????

-Larry Cochrane
Redwood City, PSN


__________________________________________________________

Public Seismic Network Mailing List (PSN-L)