----- Original Message ----- 
From: "Kevin Brunt" 
To: "psn-l" 
Sent: Tuesday, March 10, 2009 5:01 PM
Subject: Re: WinQuake


>
>
> ---- Original message ----
>>Date: Tue, 10 Mar 2009 15:03:04 -0700
>>From: Geoffrey 
>>Subject: Re: WinQuake
>>To: psn-l 
>
>>
>>Hello Master Kevin;
>>
>>This header is for a PSN TEXT FILE which I preferr to use.
>>THE other called PSN4 which I believe is a binary file mifgr work
>>differently.
>>I have not yet tried the PSN4 format because text is so much easier to deal with.
>>( Its all relative my dear einstein/watson)
>>
>>
>>Heres the headers of which I speak, One is named work and the other Dont_Work
>>********************************** CUT HERE********************************************
>>In this one your data has also been cropped to start at the right second
>>or as close as possible to that second.
>>
>>WORKS.TXT
>>! PSN ASCII Event File Format 2.0
>>Start Time: 2009/03/10 19:56:00
>>Start Time Offset: 26
>>Number of Samples:  65560
>>SPS: 18.2058
>>Time Reference Type: Oth
>>Comment:[GVA]
>>A/D Converter Bits: 8
>>Data Minimum: -33.8
>>Data Maximum:  38.2
>>Data Mean:  0
>>! Sensor Information:
>>Sensor Location: GVA
>>Sensor Description: HS10-1
>>Sensor Latitude: 33.42138
>>Sensor Longitude: -111.57477
>>Sensor Elevation: 507.5
>>Sensor Incident: 0
>>Sensor Azimuth: 0
>>Sensor Orientation: Z
>>Sensor Type: Velocity
>>Sensor Sensitivity:  7.100e-008
>>Sensor ID: HS-10
>>Magnitude Correction: 0.00235574
>>Component Name: SPZ
>>Network Affiliation: IRSS
>>Pick Information:
>>Pick Information:
>>Data:
>>
>>***************************************CUT HERE***************************************
>>          DONT WORK
>>In this one your data starts at the exact time you are trying to tell
>>winquake to use.
>>
>>! PSN ASCII Event File Format 2.0
>>Start Time: 2009/03/10 19:56:25.250000000
>>Start Time Offset: 0.000
>>Number of Samples:  65560
>>SPS: 18.2058
>>Time Reference Type: Oth
>>Comment:[GVA]
>>A/D Converter Bits: 8
>>Data Minimum: -33.8
>>Data Maximum:  38.2
>>Data Mean:  0
>>! Sensor Information:
>>Sensor Location: GVA
>>Sensor Description: HS10-1
>>Sensor Latitude: 33.42138
>>Sensor Longitude: -111.57477
>>Sensor Elevation: 507.5
>>Sensor Incident: 0
>>Sensor Azimuth: 0
>>Sensor Orientation: Z
>>Sensor Type: Velocity
>>Sensor Sensitivity:  7.100e-008
>>Sensor ID: HS-10
>>Magnitude Correction: 0.00235574
>>Component Name: SPZ
>>Network Affiliation: IRSS
>>Pick Information:
>>Pick Information:
>>Data:
>
> OK. I think the issue is about what is valid in a "PSN ASCII Event File". None of the (admittedly few) examples a quick Google 
> search has thrown up have got more than 1 decimal place in the "Start time" seconds, so it may well be that you're not allowed 
> more than one. Is there actually a definitive spec for the file format online?
>
> Also I can't find any reference to "Start time offset" at all, so there's no indication of what the units are.
>
> If you can't get the file to start at a fractional second, can you not add a sufficient number of zero samples at the start?
>
> Perhaps what's going on is that the data collection is "locked" to the 1 Hz "tick" of the external time source, so that the first 
> sample is taken on the tick. If the data is collected over a period of a whole number of seconds, there is no need to compute 
> partial seconds. And as long as the sample rate is not subject to a systematic drift, the actual rate can be calculated by 
> dividing the total number of sample by the number of seconds.

Hello  Kevin;

I think this to be the best answer so far.
My cal time is taken at synchronization then the
start time is estimated mathematically from the
tested sample rate. So if I cal at lets say
03:20:00.000 UTC I must then count backwards
subtracting time to the very first sample.

So my first time then becomes:
03:20:00.000 minus 3277 samples times 3600 seconds divided by 65541 samples per hour
the first time should be 03:20:00.000 minus 179.997253628 and nothing is to be
rounded until after all other necessary times are derived.

You need to establish a reference point then the sample times are
decided by the time displacements between them.
So if you have 1000 samples the first one is only a place holder
and you decide all other times by the spaces of time between them.
These are the only measured times and if you estimate between them
it is all sheer speculation since you measured nothing in the spaces
between the samples themselves.
There are N samples and N-1 time increments between them.
I do noy like to estimate times between the samples themselves
although it does make a prettier picture.

You never sure of the error unless you can compare
to something you are sure is correct.

I like to put a small capacitor across the input to
tickle the geophone then look at the results and compare
my times with the one I ticled with and if everytthing
is correct i get good times or so it seems.
So like I will tickle the geophone and compare the recorded time
and see that they closely match. But I can not do any better
than this without better equipment since I am no scientist
or mathmatician. Those guys have ways of testing the impossible for us to test.

But i know from experience I can be very close in
the civilian sense of close.
Like hundredth of a second.
givin I have the correct sample rate and
my hardware synchronized correctly and no
samples were either missed or duplicated during the
recording process.

My greatest problem is the sample rate.

I need the computer program to run 10X faster then the
desired sample rate or possibly faster so that
the tic counter does not change between loops.

I syncronize my sample rate to the computer tic counter
which in the old DOS machines is about 65536 samples per 3600 seconds.
In this machine it appears fast or about 65541/ hour.
Each machine will be a bit different.
Nothing seems calibrated any more.
They just build them and forget them.

It costs them too much to spudge oscillators to the correct frequency.

My ring counter depends upon the master
oscillator which needs to be exactly 12 MHz
which I can only get close to with no decent
test equipment to play with.

I do not use Larrys' equipment simply because
I want to understand the instrumentation
and kit building and programming is fun to me.
I believe I purchased the HS10 from him
but that was because I do not have the ability
to build a weather tight one for buriel myself.
Larry was my second attempt because an earlier
geophone THROUGH (RTL)??? Was faulty and I took maybe a $250+ loss
on that one that was usec and AS IS kinda thing. Dangerous buying used goods
of a scientific nature. Easy to get ripped since most such equipment
is not for the field or is not to be handled normally but with great care.
What G force has it been exposed to from here to there. Lucky if it still works
right when you get it.

Id like to go right to the manufacturer and fetch my own
equipment and deliver it to myself then and only then
am I sure how it has been handled.

Cheers;
geoff






>
> Kevin
> __________________________________________________________
>
> Public Seismic Network Mailing List (PSN-L)
>
> To leave this list email PSN-L-REQUEST@.............. with
> the body of the message (first line only): unsubscribe
> See http://www.seismicnet.com/maillist.html for more information.
> 

__________________________________________________________

Public Seismic Network Mailing List (PSN-L)