I have a question and I wasn’t able to find an answer in any of the other topics.
I am trying to capture the real-time velocity from my shake that is using a 1D geophone. However, I am obtaining very different results when extracting the velocity using the raw EHZ data, I am getting this data real time using obspy.
I tried many ways to get the velocity from it, one is integrating, another by using some filters, etc. But I just cannot make it match the velocity results I am getting from the server.
I am trying to use local data because I need this device to be independent from your server (that’s why I am not using the FDSN Server data which seems to be correct.
Since obspy only allows me to get the real time data in raw (EHZ) and I need the velocity, can you tell me what kind of process are you applying to the raw data to be able to get those values? Or what kind of process would you recommend me to get accurate real-time velocity data without having a dependency on the server?
I generated two graphics with both the local and server data at the same period of time, so you can see it’s actually quite different.
As an additional note, I of course did consider using “RSUDP” library to get the real time velocity. However this library has a lot of errors (which make it impossible to use it at this point). Also I’m not sure if the velocity values it provides are as reliable as the one you have on your server. Could you let me know if they match? In that case, I may want to invest some time trying to make that library work.
Could you post the Python code you are using to obtain the two plots? So that I can take a look and see what could be generating the difference you see? For a reference, you can check this section in our manual: Developer’s corner
Thank you!
Regarding RSUDP, I haven’t noticed particular differences between the two, but let’s take this step by step and check ObsPy first. RSUDP uses the same package in many of its functions anyway.
Of course, I attached my velocity comparison python code here. Thanks a lot for the reference, will take a look to the developer’s corner, hopefully I can find my answer there. Will let you know if I do.
That’s good to know, yes, I’ll try to make the obspy method work first and if not possible then I’ll consider other alternatives.
After reviewing your resource, I got a lot of good information, thanks! So I had an idea. I wasn’t using the inventory file for my velocity calculation because it has to be server-independant. But I downloaded it and uploaded it through SSH to my shake, so I could still use it for my local velocity calculation.
After doing so, I get results that are much closer and I believe I can probably make them equal by creating an empirical correction factor. But by default, they still are a bit different, so I am still trying to understand why.
Thank you for sharing the code you are using. There are two things that may be behind what you are seeing:
The first is that you are not removing the instrument response (as far as I can see) before operating on the recorded trace/stream. This can help you: Metadata - Instrument Response Files
I think double detrending is not necessary, unless you require the second detrend operation for the study you are doing. The first one (st.detrend("demean")) should provide you with the correctly adjusted dataset.
Also, in the local trace, I see you are integrating to obtain velocity. When you remove the response, this operation will become redundant as ObsPy’s remove_response function will take care of that: obspy.core.trace.Trace.remove_response — ObsPy 1.4.1 documentation
These are some points you can focus on and see where to go after you check them.
Thanks a lot for your comments. In the second file I was actually removing the instrument response, but I did have the duplicated detrending so I removed it. I also removed the second integration.
With that, a few changes on the filtering and by adding a correction factor I obtained very similar results now, which is functional for me.
