Create Validator Test to Constrain the Upper Bounds of ResponseList

[timronan]

IF max(ResponseList:Frequency) < Channel:SampleRate/2 [Nyquist Frequency] than Fail.

Resposnelist frequencies must not exceed a systems Nyquist frequency because this portion of the response would represent an aliased signal.

[chad-earthscope]

Hmmm, not sure this is correct. If a sensor is described with a ResponseList which may be across its entire useful band, and then a later decimation stage reduces the Nyquist to well within the sensors described response, that seems OK. This rule would require the same described sensor response list to be "truncated" differently depending on the final sample rate of the channel.

[timronan]

Is the response list used to describe only the sensor or is it intended to describe an entire response? It seems like all the responselist formatted metadata stored in the IRIS database uses a response list to describe the entire response rather than just the sensor.

Here is an example:

https://service.iris.edu/fdsnws/station/1/query?net=IM&sta=VNDA&cha=BHE&starttime=2001-01-31T00:00:00&level=response&format=xml&includecomments=true&nodata=404

[rcasey-earthscope]

Hi Tim- I think that Chad was referring to reference frequency at each stage of a PZ + FIR response, to which I think his point is correct. I think you meant something different. Your example shows an array of Frequency, Amplitude, Phase tuples, which progresses right up to Nyquist for this instrument. Was your rule meant to apply to this FAP array? -Rob

…

On Feb 8, 2021, at 3:04 PM, timronan ***@***.***> wrote: Is the response list used to describe only the sensor or is it intended to describe an entire response? It seems like all the responselist formatted metadata stored in the IRIS database uses a response list to describe the entire response rather than just the sensor. Here is an example: https://service.iris.edu/fdsnws/station/1/query?net=IM&sta=VNDA&cha=BHE&starttime=2001-01-31T00:00:00&level=response&format=xml&includecomments=true&nodata=404 <https://service.iris.edu/fdsnws/station/1/query?net=IM&sta=VNDA&cha=BHE&starttime=2001-01-31T00:00:00&level=response&format=xml&includecomments=true&nodata=404> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL4VN3X4GHARGRSRFZIVTDS6BUXJANCNFSM4XJ27XPA>.

[timronan]

Hi Rob,

Yeah this rule would be designed to check on FAP array tables, responselist, similar to the example. I should have posted this example when I opened the issue.

[kkappler]

Hi,

Karl here, I had suggested this rule last week. To clarify I meant only that the FAP table should provide a data point at or higher than the Nyquist of the time series which will be ultimately archived and downloaded by a user.

This constraint ensures that a user would not have to extrapolate the response function to high frequency when calibrating their data.

The specific instances of response tables I am thinking of are typically provided by the manufacturer and have a fixed number of rows (or frequencies) at which a spectrum analyser or similar tool was used to characterize the instrument. This table would in general not need to be truncated. The normal workflow I had in mind would be to define a function based in interpolation of the FAP table (usually in loglog space), and then evaluated that function at the frequencies relevant for a given time series.

The evaluation frequencies would be dictated in the users workflow depending on the number of samples and sampling rate of their time series chunks, but as long as we have a data point at the Nyquist of the highest archived sampling rate, then the user can always define the response all the way to the edge of their spectrum.

Karl