Hi Wayne,

At 10:13 PM 9/3/99 -0400, you wrote:
>Larry
>
>The attached email is a response to a timing difference I found while
>going through an interim solution which involved data submitted to the
>USGS by both the SRU and the DPSN. I found that the P-wave arrived at my
>station before SRU stations which were closer to the epicenter. A
>station 5km closer to the epicenter had an arrival time 0.15 seconds
>later than my station.

A few years ago I thought I saw a problem with the local USGS timing. When
I looked at the records from the telemetry stations I record compared to
the same station recorded by the USGS, I saw a ~150 ms difference. It
turned out to be the propagation delay through the low pass filter on my
Demod card. At that time I was using two 8 pole switched cap filters. This
caused a very long delay through the two filters of about 70 ms each, when
the cut-off freq was set to 10 hz. I think the propagation delay changes
somewhat with cut-off freq. So I did two things. I removed one of the
filter chips (a MAX 291) and added a menu item to SDR called "Filter
Delay".  This is used to compensate for the filter delay. 

If your SDR system was locked to the GPS receiver at the time of the event,
your timing should be within a few milliseconds. If you see the (L) time
indicator in WinQuake, SDR was locked to GPS at the time of the event file.
One thing you should check to see is if you have anything in the "Filter
Delay" field. I don't think this is the problem because you are seeing the
P wave before the expected time.  I'm assuming you are looking at the
geophone records and not the telemetry records... For the Amp / Filter card
with a ~20 hz low-pass filter the delay should be about 50 ms. 

Too check the timing, heres what you can do. Take the one pulse per second
output signal from the GPS receiver and feed it into one of the A/D
channels. First do it without the Amp in the path. If the GPS receiver is
locked (seeing enough satellites)  you know that the 1 pps signal is within
1 us of the correct time. Now create an event file and look at it with
WinQuake. The low to high transition should be at the top of each second
and within one A/D sample.  

I haven't tried this but you should also be able to measure the filter
delay by feeding the 1pps signal into the amp card. But you MUST divide the
signal down with a resistor divider. You don't want to saturate the input.
It won't hurt the card, just screw up the measurement. What you want to do
is find a resistor value that will keep the output under +- 32k A/D counts.
When you look at the event file you should see a rounded signal with some
delay from the top of the second. 

As far as the problem you are having, not sure. Could elevation have
something too do with it? Also the type of ground the sensors are over can
make a lot of difference. Maybe Edward or others on the PSN-L list have
some thoughts....

>
>The person who wrote the email, is the volcanologist on island. Do
>you have any input on the information he gave me?

My comments below...

>Wayne Abraham
>1430 Rodney Street
>Portsmouth, Dominica

>hi Wayne
>....
>
>On the issue of timing, it appears very unlikely that
>the problem is with our system.  We've invested a lot
>of time and technical expertise on this issue, in fact
>as recently as the last few months. 

This could be correct... but when I was working with the local USGS about
the timing problem I was seeing with my system and theirs, they did find a
problem. At the time they had two systems, one recording the triggered data
and another doing the P picks. I pointed out too them that their
seismograph records, not the ones form my system, showed a different time
for the P arrive then their P picking system. The guy I was working with
went over too some equipment and sure enough it was switched to a wrong
timing source! Its been a while, I think the error was about 50 ms. They
sample at 200 sps.  

> First, in order
>to obtain your quoted accuracy your data sampling rate
>would have to be in the region of 20 megahertz.  

I'm not sure what "quoted accuracy" you gave him.  If its a few
milliseconds, maybe he thought microseconds, this is not correct. SDR uses
a 1 ms interrupt, not the PC time, so timing accuracies can get down to 3 -
5 ms, if used with a GPS receiver. A little more with WWV and WWVB. Since
the max sample rate of SDR is 100 sps, or every 10 ms, each sample should
have accurate timing.

>This
>would mean, for a three component station, recording
>60 Mb of data per second.  Typical sampling rates are
>more like 20 Hz, which due to signal processing theory
>gives a best possible accuracy on arrival times of
>0.1 seconds.  

Given that it takes a few samples to detect the P wave, 100 ms sounds about
right at 20 hz or 50 ms for each sample.  If they are only sampling at 20
sps this could be a large part of the error you are seeing. 

>I say 'best possible' because it takes
>much more than using a gps clock to correct the pc
>clock, since system limitations end up giving this
>timing accuracy an error of +/- 1 second.  

Again, SDR does not use the PC clock except to seed its internal time when
the program first starts up. After that, it uses the 1 ms interrupt
generated by the A/D card for all timing, and hopefully some time
reference. Since SDR only runs under DOS, there shouldn't be a problem
keeping up with the 1 ms interrupt. If the system drops a lot of interrupts
(it will do this under Windows), there will be timing problems. You can
check for this in the SDR.LOG file if you have the debug mode on. If you
see large correction times, you are losing interrupts or some other TSR or
driver is disabling interrupts for a long period of time. 

>We have
>been able to by-pass the pc clock and correct the
>seismograph clock directly from the gps incoming
>data stream, and also sample at 100 Hz.  We get an
>arrival time accuracy of 20ms as a result.  So the
>timing discrepancy more likely comes from your system.

Running the time signal through the A/D system is one way of doing it...
The other way is to control the sampling and timing the way SDR, and I'm
sure other data logging systems, do it....

-Larry Cochrane
Redwood City, PSN


_____________________________________________________________________

Public Seismic Network Mailing List (PSN-L)