Data calibration off in special use case

Hi all,

I’m brand new to this, so please bear with me as I walk you through my process and the resulting questions. I even read the manuals. Well, I searched the manuals, but only found enough to get me in trouble. :slight_smile:

So I installed the brand new RS4D I received yesterday. I chose the 4D specifically for the MEMS sensors to measure building sway. I live on the 50th floor of a 54 floor building, and in decent wind we sometimes feel noticeable sway (which is normal and even desirable as the structural engineers amongst you will tell me). My aim is to measure the displacement on my floor level in N/E/Z.

I’ve set up both swarm and rsudp to visualise the data. Both produce sensible graphs, I can connect to the local device with swarm, and it’s sending its data to the online servers. So far so good.

I read about the automatic calibration to create the instrument response file, so I let it run for a few hours and switched the rsudp units to displacement (units: DISP). This worked as expected - see plot below - and looking at the instrument response file it appears to have done some magic and came up with some solution.

The scale however is way off: rsudp is showing displacements in the +/- 5-20km range. Yet my seahorses are still in their tank, so it’s probably fair to say the calibration is off. I was assuming to find values on order 10e-2 - 10e-4 meters (cm to mm range). We have a nice wind storm with 60-70km/h wind gusts going at the moment and I can see the displacement waves in NN/NE and to a much lesser extent NZ, exactly as expected. So this is super exciting, except the scale is off. Screenshot for a thousand words:

This isn’t terribly surprising I suspect given my use case is not what your auto calibration method had in mind.

So here come the questions:

  • Do I need to / Can I create my own instrument response file - or can I just linearly scale the data? If so, can a scale factor be fed to rsudp via config file? Or do I need to adjust the instrument response file manually, and then feed that to rsudp? The documentation mentions that you can supply your own instrument response file, but it doesn’t say how.

  • Is it possible to force rsudp to show all three MEMS sensors on the same scale?

  • swarm doesn’t seem to use the instrument response file to show calibrated data. I can only display raw counts in the plots. yet I see other people’s stations that are showing their geophone output in velocity? How can I enable that for my output?

Cheers

Balthasar

Ok this is quite exciting… I hung a pendulum from the second floor down (read: cat toy rope with an old pan attached) and was able to see the building sway with that pendulum (and in the sea horse tank simultaneously). The amplitude of the pendulum was around 1cm - when the RS4D indicated 10km displacement - so we’re about 6 orders of magnitude out with the “calibrated” displacement data.

Hello from Panama @zeedoktor !

Thank you for your enthusiasm and welcome to the Community.

What do you men “automatic calibration to create the instrument response file”? Did you create your own instrument response file from scratch somehow? Or did you use our published instrument response file?

re: bullet point #1: We automatically generate the instrument response file for you when you turn data forwarding on (at https://rs.local/). Do this, then find your station at stationview.raspberryshake.org, click on it and hit the “Download instrument response” link on the left hand panel.

re: bullet point #2: @stormchaser, can you answer this question?

re: bullet point #3: Correct, when connected directly to the Shake, there is no instrument response information passed from the Shake to Swarm and it is not possible to configure this information locally in the Swarm config files; When connected to the Raspberry Shake Data Center, the Data Center’s server passes Swarm the overall gain. We recommend using dataview.raspberryshake.org and not Swarm.

branden

Hi Branden, thanks for your responses (and greetings from Sydney where we finally are no longer locked down!)

by “automatic calibration” I meant the automatic generation of the instrument response file and upload when connected to the server. I was/am assuming that the displacement values rsudp calculates use that instrument response file for calculating physically accurate measurements. The fact that the displacement values are out by 6 orders of magnitude then either means

a) I don’t understand what displacement is. I think it means displacement of a “virtual” particle on the floor as the ground moves, so should be on order 1-2cm in the wind storm we had yesterday. Not 20km…

b) the fact that my shake is on level 50 in a high rise where there’s a lot of ground noise and sway has resulted in a faulty instrument response file, because that is understandably not the use case for the shake, you’re expecting solid ground. if that is the case, how can I get rsudp to “fake” it, i.e. scale the data by an amount I can ideally supply in the configuration file?

I mean, at the end of the day I can always roll my own version of rsudp, or even something completely from scratch using obspy, but I’d prefer to minimise effort on my part, and maximise benefit to the community. I’m pretty sure I’m not the only one with the building sway monitoring use case with an RS4D.

And lastly, if you or anyone else reading this has any suggestions on other software that is perhaps specifically geared towards monitoring a building using a raspberry shake, please let me know! I also just placed an order for a RS3D I’ll place in the underground parking. That’ll make for an interesting comparison.

Cheers

Balthasar

dataview.raspberryshake.org is only showing data until yesterday sometime - this despite server connection up and data in swarm from server is available (not the local connection).

Hello Balthasar, welcome to our community from me too!

Regarding your question:

  • Is it possible to force rsudp to show all three MEMS sensors on the same scale?

Yes, but it is not an option that can be enabled by modifying the rsudp_settings.json file. To do what you suggested, you would have to manually edit your RSUDP installation, editing the c_plot.py file (and eventual files related to that) establishing a set of variables that will be the same for all the plotted channels.

Regarding the connectivity issue, there must have been something preventing the connection of the Shake on October 17th, but data is now flowing again: RS DataView BETA

You can download your response (in a pre-set data schema) here: https://fdsnws.raspberryshakedata.com/fdsnws/station/1/query?network=AM&station=R8A4D&level=resp&format=sc3ml

or here in another pre-set schema, if the software has problems with the first one above: https://fdsnws.raspberryshakedata.com/fdsnws/station/1/query?network=AM&station=R8A4D&level=resp

For the rest, I call out to our community too! Is there another user that has had (or having) a similar experience with a Shake located near the top of a tall building?

Hello zeedoktor

I have worked with strong motion record of buildings. The application you propose is very interesting and practical and practical but requires careful processing to obtain reliable DISP.

An alternative to what you indicate that you could implement is to download the data by time intervals with Obspy from the x, y and z channels. Then apply the conversion factors that correspond to the version of your RS4D to obtain the values in m / sec2 at the same scale.

Values that you can process with any suitable method to process seismic records (strong motiom type) and obtain the displacements. Process that you should review carefully because algorithms can have problems when they have low accelerations. Perhaps Rsudp has trouble calculating DISP due to the low accelerations that the wind usually produces.

You can also obtain with the same data, information on the building’s modal frequencies.

Alejandro

1 Like

Thank you @Stormchaser and @Alejandro, very useful information. I’ve started going down the “roll my own” rabbit hole. I’m creating a new thread in the developer forum as that topic probably no longer qualifies as a technical support issue.

Cheers

Balthasar