Pole Zero Correction using OBSPY and PSN Data Obspy provides the possibility of instrument response correction. WinSDR and WinQuake already have capability to embed the required information into the event files. There is no need to fear the math complexity as all the numbers can be simply related to what is already within your station processing. There are 3 main considerations in response correction. One is time delay, the second is amplitude, and the third is phase correction. Take these one at the time. Time delay occurs within the data gathering and processing. Think about your AD converter. It may average 240 samples per second to provide a sample rate of 30sps. Therefore each data point represents 8 samples gathered over the preceeding sample interval and the delay is delayed by approximately one half of the sample interval. An anti-alias filter may delay further by several sample intervals. WinSDR documents provide this information: Sensor Filter Delay Field: The Filter Delay setting is used to compensate for the propagation delay of the signal through the low-pass filter connected between the sensor and the A/D card. This is done by subtracting from the start time of the event file the number of milliseconds entered in this field. To measure the delay of your filter you will need a signal generator with a square wave output and a oscilloscope with two channels (or you could use two WinSDR channels). Feed the square wave into the amp / filter card. With the O-Scope or WinSDR look at the input signal with one channel and the output of the filter with the other. Measure the difference between the input and output signal in milliseconds and enter that number in the Filter Delay field for the channel. If you are using my Amp / Filter board with a 10 Hz low-pass filter you should use a value of around 50 milliseconds. For PSN-ACCEL and PSN-ADC24 boards running at 100 SPS or higher a value of 20 milliseconds can be used. The delay can be adjusted in your data using the starttime delay feature of WinQuake or set into WinSDR settings. There is really nothing new or difficult about this adjustment. With my digital anti-allias I use 1.016666 seconds representing AD averaging plus 30 samples delay in the digital filter. Second is amplitude correction. Here again most of you are already implementing some form of this. The sensitivity, AD voltage and amp gain provide conversion from counts to nanometers centimeters volts or whatever scale you are using for display locally. WinQuake documentation provides a calculator to compute a correct sensitivity number for your station. This number is related to a SAC pole zero file gain called the constant by a factor of gain=100/winquakesensitivity. The output voltage in WinQuake is related to your magnet coil commonly called G by a factor of 100 also since WinQuake corrections are defined at the centimeter level rather than at a full meter. For the common magnet coil sensing arrangement a velocity output of volts per 1 meter per second is the standard reference. The sensitivity and amp gain numbers then translate the output to the recorded level. Finally, the phase correction is a bit more involved but can be figured out with some available tools. This document will use SeismoWin for ease creating graphic display. Brett has also provided a spreadsheet to the PSN that will accomplish the same computations for you. For simple pendulum sensors the period and damping which you already have set are used to get the poles and zeros. The following example is based on a 2.78 second period vertical instrument quite similar to an AS1 configuration.
The first things we need are period, damping, and 'G' or gain of the pickup coil. These numbers are entered into the Seismowin sensor block. The first graphic shows the source data and the second graphic the resulting poles and zeroes. Note also the A0 of 1.043649 and gain 10.391 normalized at 1 hz which we will use later. Also note the marker in rad/sec and marker in Velocity as we are correcting for a velocity sensor. The next image shows input numbers for the instrument. Period, damping, and G. The plot shows amplitude response dropping below the natural frequency and the phase shift induced. The output shows 2 poles and 2 zeros, a0 and gain for the stage.
Now consider the amplifier portion. A circuit simulation program should be able to correctly provide the poles and zeros for the circuit. I do not have that capability so my inputs are estimated using other methods. Note the amplifier has a flat top curve reaching much lower in frequency compared to the pendulum stage. The phase changes are a much more complex curve. Poles and zeros are shown below.
If the 2 stages are combined we find that the poles and zeros are simply listed together and the gains are multiplied as logic would probably lead. This section is also done in velocity and radians/sec. Now consider the AD. As most AD converters will not have gain and should not have an affect on the data the expectation would be gain of 1 and no poles and zeros.
Our guess was almost correct. There is a gain because the AD converts 1 volt to 3276.8 bits in the data stream. Our final recorded level is in bits/meter/second. Now all the pieces are in place to perform instrument response correction. Using WinSDR, the poles and zeros can be loaded in the following format and they will be added to the data files saved from the channel.
Example Poles and Zeros File to be used with WinSDR and based upon the above discussion. nzeros=3 Requires change to 4 for displacement npoles=5 z0=0.000000e+00,0.000000e+00 z1=0.000000e+00,0.000000e+00 z2=0.000000e+00,0.000000e+00 z3= (This should be added to the velocity zero list to make displacement) p0=-1.808000e+00,1.356000e+00 p1=-1.808000e+00,-1.356000e+00 p2=-1.772000e+01,1.772000e+01 p3=-1.772000e+01,- 1.772000E+01 p4=-1.900000e-02,0.000000e+00 When this pole zero information is combined with the sensitivity number which is also available in the WinSDR channel everything needed for instrument response correction is available. The information above is related to a SAC pole zero format as produced by the rdseed program. It will be noted that we need one more zero as indicated. The added zero will convert to a displacement output of the corrected data. It corresponds to integrating your event file before computing magnitude in WinQuake. The final system response to velocity is shown below with a correction to a displacement response directly below for comparison. Next is displacement.
Also, the SAC format uses a constant representing gain. Comparison will show that taking the WinQuake sensitivity in cm/sec/adcount and dividing it into 100 to get counts per meter per second is the needed conversion. The readpsn() program will perform the conversion and attach the correct information accessed by the variable trace.stats.response.paz.sensitivity if WinSDR has been set up with this number. In [57]: rp[0].stats.response Out[57]: AttribDict({''zeros': [0j, 0j, 0j, 0j], 'sensitivity': 111910650.536, 'poles': [(-1.876+1.261j), (-1.876-1.261j), (-27.768+27.768j), (-27.768-27.768j), (-0.05+0j)]}) So how does the constant relate to the system definition we created? By placing the numbers into a RESPONSE file format we can see the relationship and also learn about the RESP format. Examine this resp file looking for A0, gains, and sensitivities. # ################################################################################### # B050F03 Station: RPSD B050F16 Network: AM B052F03 Location:?? B052F04 Channel: MHZ B052F22 Start date: 2008,155,00:00:00 B052F23 End date: 2599,365,23:59:59 # # +-----------------------------------+ # Response (Poles and Zeros) # AM. RPSD MHZ # 06/04/2008 to 12/31/2599 # +-----------------------------------+ # B053F03 Transfer function type: A B053F04 Stage sequence number: 1 B053F05 Response in units lookup: M/S - Velocity in Meters Per Second B053F06 Response out units lookup: V - Volts B053F07 A0 normalization factor: +1.055693E+00 B053F08 Normalization frequency: +1.00000E+00 B053F09 Number of zeroes: 3
B053F14 Number of poles: 5 # Complex zeroes: # i real imag real_error imag_error B053F10-13 0 +0.00000E+00 +0.00000E+00 +0.00000E+00 +0.00000E+00 B053F10-13 1 +0.00000E+00 +0.00000E+00 +0.00000E+00 +0.00000E+00 B053F10-13 2 +0.00000E+00 +0.00000E+00 +0.00000E+00 +0.00000E+00 # Complex poles: # i real imag real_error imag_error B053F15-18 0-1.87600E+00 +1.26100E+00 +0.00000E+00 +0.00000E+00 B053F15-18 1-1.87600E+00-1.26100E+00 +0.00000E+00 +0.00000E+00 B053F15-18 2-2.77680E+01 +2.77680E+01 +0.00000E+00 +0.00000E+00 B053F15-18 3-2.77680E+01-2.77680E+01 +0.00000E+00 +0.00000E+00 B053F15-18 4-0.050000E+00 +0.00000E+00 +0.00000E+00 +0.00000E+00 # # +-----------------------------------+ # Channel Sensitivity/Gain # AM RPSD MHZ # 06/04/2008 to 12/31/2599 # +-----------------------------------+ # B058F03 Stage sequence number: 0 B058F04 Sensitivity: +1.06007144E+08 B058F05 Frequency of sensitivity: +1.00000E+00 B058F06 Number of calibrations: 0 A0 enters directly from the first stage sensor entry. It is the number that places the graph at a standard level of 1 at the normalizatin frequency of 1hz. The poles and zeroes are the complete list produced be listing all poles and zeros for all stages together. The final sensitivity is the product of sensor gain 10.391 times amp gain of 3162.278 times AD gain value of 3276.8 counts per volt for a total of 106,007,144. This example is bad because I have these rolled up into one number. Converting the response file to the SAC format requires multiplication of A0 with sensitivity for 1.043649 times 106,007,144 for a constant of 1.11911e+08 counts per meter. This is counts per meter. In WinQuake this would be sensitivity of 8.9357E-07 cm/ count. The number is obtained by dividing by 100 and then inverting the result. In this example all the gains are combined before building the file. In reality with a more complex system each stage can be included seperately. The final stage will be stage 0 with the total sensitivity listed as shown here. In the next section some examples will be used to show verification of the WinQuake conversions and to provide some examples of how Obspy can be quite simple to use.
This event file will be used as an example as we continue with response correction. The code used will be shown as the example progresses. First read in the data and response. I do not record using WinSDR so I will use a SAC format file developed above and attach using some different code available in Obspy. Code is blue. filename = 'C:\Documents and Settings\Randy\My Documents\PyProgs\docevt.psn' respf = 'C:\Documents and Settings\Randy\My Documents\PyProgs\PZrp.txt' #define a filter band to prevent amplifying noise during the deconvolution. A similar filter was run in WQ attempting to balance the plots not using this. pre_filt = (0.05, 0.1, 6.0, 10.0) These next lines will attach the pole zero sensitivity to the trace while reading. rp = readpsn(filename) attach_paz(rp[0], respf, tovel=false) rp.detrend('demean')
rp.plot() #uncorrected data plot is produced The plot below shows the Winquake sensitivity included as noted on the scale. Resp1 is then extracted from the trace for the next operation as a test. Note SAC format response corrects to displacement so tovel=false was the correct switch setting when attaching the response information. resp1 = rp[0].stats.paz rp[0].stats.calib = 1.0 the calibration is set to one to prevent double correction. Now the correction is applied by removing the paz and correcting the amplitude. rp.simulate(paz_remove = resp1, pre_filt=pre_filt, paz_simulate=none) rp.plot() #corrected data plot showing displacement. In WinQuake the approximate matching operations would be to integrate the data.
The next plot then is of data integrated in WinQuake and then amplitude adjusted by the WinQuake sensitivity. I have renamed the integrated trace from rp to psn in order to keep things in order. psn[0].data = psn[0].data*(psn[0].stats.calib) psn.plot() As a final verification of the processing the next plot will show in blue the uncorrected Welch Periodogram. This is an average of overlaping fft windows which smooth the data and bring out any long term frequencies while averaging the noise level.
The top blue line is uncorrected data in the velocity domain. Green is the pole zero corrected to displacement and adjusted for gain. Red is Winquake integrated to displacement and corrected by the velocity sensitivity number but with no poles or zeros applied. Note the displacement corrected data has a different slope. As the lower frequencies are reached the pole zero adjustment increases bending the curve upward. There is a lower limit on correcting response and the lower frequencies are boosted beyond usable information levels. The pre-filter cut shows on the left edge preventing unwanted noise amplification. The next 3 images are zoomed in on the first P arrival time.
The uncorrected data. The arrival corrected to displacement. The integrated WinQuake data corrected for amplitude. Note phase differences.
The final graphic is taken from an Obspy document. It graphically shows what takes place in the correction.