RPZ Broadband 2009 - instrumental response introducing latency ?

[salichon]

• "Sandra bourguignon"

• 2009 data trace seismic

• Some RPZ HH picks looks being early for ~1 seconds

• This looks like it s related to the instrument response

• [x] Sandra to provide more context

• [x] Sandra to describe the process from the data, picks and deconvolution

---

• RPZ is a CTBTO station and should have an identical set up to other CTBTO station
• Mark suggested this may be related to data latencies - Raw data to be checked.

RPZ response:

https://service.geonet.org.nz/fdsnws/station/1/query?network=NZ&station=RPZ&level=channel&channel=HH1&startafter=2003-01-01T00:00:00.000&endbefore=2015-11-01T00:00:00.000&level=response

URZ is another CTBTO station and should have the same set up and response type

https://service.geonet.org.nz/fdsnws/station/1/query?network=NZ&station=URZ&level=channel&channel=HH1&startafter=2003-01-01T00:00:00.000&endbefore=2015-11-01T00:00:00.000&level=response

[segburg]

Applying the instrument response introduces a visible phase shift including a time shift of ~1s. The attached figure shows the trace before and after the instrument response I am attaching also the data, instrument response and code.

from obspy import read from obspy.core.utcdatetime import UTCDateTime from obspy.clients.fdsn import Client

topdir = 'C:/Users/sandrab/Documents/tstar/' client = Client("GEONET") inv = client.get_stations(network="NZ", station="RPZ", channel="HHZ", starttime=UTCDateTime("2008-01-01T00:00:00"), endtime=UTCDateTime("2020-01-01T00:00:00")) inv.write(topdir + 'station-xml/inv_RPZ.xml', format='STATIONXML') tstart = UTCDateTime("2009-11-09T14:02:27.6") tend = UTCDateTime("2009-11-09T14:02:57.6") julday = tstart._get_julday() st = read(topdir + 'sds/2009/NZ/RPZ/HH.D/' + str(julday), starttime=tstart,endtime=tend) pre_filt = [0.001, 0.03, 30, 40] for tr in st:

tr.remove_response(inventory=inv.select(channel=tr.stats.channel), output='VEL', water_level=60, pre_filt=pre_filt, zero_mean=True, taper=True, taper_fraction=0.10, plot=True)

[segburg]

There is no time shift when applying the "same" instrument correction but for a recent period (2019). URZ (same sensor and datalogger as I understand) shows the same behaviour: a time shift for earlier times (2009, 2013) and no time shift for a recent time (2019) .

[ozym]

I have identified that the sensor response for these two sites is suspiciously not matching the phase response, the amplitude response appears to be okay. I've checked the manufacturers specifications and they appear to have been correctly transcribed.

This will need some more investigation.

[segburg]

Hi Mark!

Thanks so much! Hopefully it won’t take them too long with the lockdown! Cheers Sandra

[ozym]

I think I've worked out where the delay is coming from, the decimation filters have two values, a delay and a correction. These are the same in all cases here and when applied will provide zero delay. However, if the assumption that a delay is required (and the correction isn't taken into account) then an offset will be applied when removing the instrument responses. It's safer if these are removed from the response files (as this delay is handled inside the datalogger) and shouldn't need to be applied.

[segburg]

Hi Mark, I see, indeed each delay seems followed by a correction in the station xml. Is the problem related to the software not applying the correction or is it redundant as already applied in the datalogger? Just trying to understand. Will you take these out of the metadata or do you recommend that I delete the two (delay+correction) lines in the station xml? Thanks for your help, Sandra

[segburg]

Hi Mark, Is the phase response ok? I understand that there is a 180 phase shift. For what frequency range is this flat? Do you have a plot of it perhaps? Thanks Sandra

[ozym]

I've looked at the phase response and it seems pretty flat between 40 seconds to about 20 Hz (the phase shift only comes about when you reference it to something).

[segburg]

Can you clarify "the phase shift only comes about when you reference it to something".

[ozym]

From https://www.passcal.nmt.edu/response_plotter with the poles/zeros added ....

[segburg]

Thanks for your help, I could get rid of the time shift by setting the parameter in the station xml file to zero. Will this also be corrected in the metadata obtained through the fdsn service?

[ozym]

If you use the latest version of the responses from FDSN web services at geonet, this should have been updated.

[segburg]

Hi Mark, I just noticed that LTZ shows the same 1s delay for the period that I am looking at (2009-2013). It seems that it was equipped with the same datalogger Q4120 as RPZ and URZ were. Hence, the same Delay and Correction parameters appear in the response. Note I am looking only at a small set of broadband sites in the South Island. Cheers Sandra

[segburg]

Hi Mark, I just tested the new instrument response for RPZ downloaded from the fdsn service but the 1s time delay is still present. The Correction parameters are still the same values as before. I assume this hasn’t been updated yet? Cheers Sandra

[ozym]

The code has been updated, just waiting for it to make its way onto the servers.

[ozym]

@segburg That looks better, try again now.

[segburg]

Great,… just tested it 😊 Sorry I didn’t expect such a response at this time of the night. Have some rest! Thanks again, Sandra

[salichon]

Cf: https://github.com/GeoNet/delta/pull/801

[salichon]

I deem that this RPZ 3009 metadata help ticket is resolved now (9 April 2020)

[segburg]

Yes Jerry

From: jerry notifications@github.com Sent: Friday, 5 June 2020 15:17 To: GeoNet/help help@noreply.github.com Cc: Sandra Bourguignon S.Bourguignon@gns.cri.nz; Mention mention@noreply.github.com Subject: Re: [GeoNet/help] RPZ Broadband 2009 - instrumental response introducing latency ? (#68)

I deem that this RPZ 3009 metadata help ticket is resolved now (9 April 2020)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/GeoNet/help/issues/68#issuecomment-639233316, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMOGJKEGW3YS3FSX5GWC23RVBPRLANCNFSM4LZZYJMA.

Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents.