I am doing some comparison tests between a Nanometrics Trillium Compacts 20s (with Centaur data logger) and a RaspberryShake 3D (V5). I downloaded the nominal sensor responses from the IRIS NRL and from RS web site (http://manual.raspberryshake.org/) for the former and the latter, respectively.
When I perform the crosscorrelation of data collected by the two sensors placed one next to the other (after Nanometrics data have been deconvolved with Nanometrics nominal response (Centaur+Trillium) and convolved with RS one), I systematically obtain a positive delay of about 0.49 s (RS data are delayed wrt Nanometrics ones). I am wondering what this delay could be due to. When running JEvalResp routine to compute sensor responses for deconvolution/convolution, I obtain the output in the attached image. I think the reported delays are introduced by decimation and anti-alias filtering, but it is not clear to me if the calculated delays are corrected for. By the way, the sum of Nanometrics and RS calculated delays is approximately 0.49 s.
Could anyone give me some help about that?
I also attach the nominal response files that I used.
Thanks very much
out4.response.restored-EHZ-plus-decimation-new (7.8 KB) RESP.XX.NN430…HHZ.CENTAUR.1.200.0_001.LP (34.2 KB) RESP.XX.NS348…BHZ.TrilliumCompact.20.753 (5.5 KB)
Good day Diego. Thank you for posting to the forum. Please send raw waveform data.
Please find attached an example of raw data. Please note that RS and Nanometrics data are collected with sampling frequency of 100Hz and 200Hz, respectively.
Data have been collected by placing RS and Trillium sensors on asphalt one next to the other and have already been cut over a common time span. Timing was provided by GNSS.
RS2524_cut0840_1055.mseed (5.7 MB) → Raspberry Shake data
STN13_cut0840_1055.zip (7.8 MB) → Nanometrics data
I opened the raw data with SQLX and confirmed a 0.5 second timing error. One of the two sensors had bad timing. Now you have to run some more experiments to see who was the culprit!
Let us know how we can help.
Interesting, you have proven 2 things:
- The convolution routine you are using works; and
- The response file does not introducing timing issues
Thanks for your feedback.
I assume your image displays the raw data. If this is the case, yes, the deconvolution-convolution sequence I apply does not introduce any time shifts. However, I think this is a bit odd because if you take a look at the phase responses of the sensors computed with the JEvalResp routine, they are not zero (especially the RShake one – say in the 0.7-39Hz band).
Accordingly, I would expect distortion and time shifts in the raw data to be compensated for when applying the deconvolution-convolution sequence. Am I correct?
By the way, I am still wondering if and how the Calculated delay, the Estimated delay and the Correction applied parameters computed with the JEvalResp routine (see my first post above) are used in the deconvolution-convolution process. Maybe it would be helpful for me if you could send the complex frequency response function (real + i*imag, mag & phase, whatever) of the RaspBerry shake 3D V5.