Raspberry BOOM



I have a question on Raspberry Boom, What units use?, How can I see in fisic units, the data on swarm?


Welcome Masaldivar.

I think you will find elsewhere that OSOP have not published an accurate calibration of the Boom yet. It is promised.

However if you consider that 1 meter elevation change equals about 12 pascals pressure change, you can guess the calibration.

This, however, is not easy to do :wink:

But won’t there be a V^2/2g effect that you’re not accounting for?

I increased the mechanical filter to 20 seconds to give more time to see what is going on. It appears that there is a substantial effect due to acceleration of the unit (a seismic sensitivity). The seismic effect is much bigger than the air pressure change. This injects a pulse into the on-board electronic filter that tends to cover up the actual pressure change. It appears that the seismic response direction is opposite the direction of acceleration. In other words there is a negative pulse as I begin to lift the unit and a positive pulse as I slow the movement to a stop (e.g., 13:56:44).

So it turns out that the last part of the pulse is always in the opposite direction of the air pressure change. This tends to cancel out the desired result for 5 or 10 seconds.

The remaining part of the change (before the mechanical filter bleeds to zero) looks to be about 25K counts. One might imagine that the change due to air pressure, without the acceleration effect, could be (very roughly) 50K counts or, in round numbers, 4k counts per pascal.

Coincidently, the number 4000 appears in the “download instrument response” file…

Thank you very much,

As an after thought, tonight I tried the “use calibrations” wave option in the SWARM program - which up to now has had zero effect on anything - and was interested to see that now the waveform display switches to pascals. And the conversion between counts and pascals can be seen to be 4000 counts/pascal, as expected.

I imagine that the actual sensitivity will vary with frequency and probably be affected by any “plumbing” added ahead of the unit …

These 4000 counts/ Pascal is a placeholder. The actual Sensitivity has not been calculated yet, but this is in the works. When it is ready, the metadata used by Swarm will be updated.


I saw where the RBoom calibration number has recently been determined to be 56000 (That is counts/pascal I assume?)

I calculate, if you raise the unit about 1 meter, the pressure reading should drop by about 672,000 counts (11.7 x 56000). With a 20-second filter on the discharge, that delta-P should stay in effect long enough to produce some readings of this magnitude. I was not seeing that. Are you seeing that? Assuming your calibration was done with some sophisticated and well calibrated instrument it must be right. So why doesn’t the raise/lower test work?


Yes, that is correct!

Yes, a 1 meter change in barometric pressure should be roughly 10 Pa (560k counts). Up = negative.

What did you see?


I was referring to this old posting:

Summarizing - with some interpretation of the meaning of the results and extrapolation - I got about 50,000 counts for 1 meter.

The challenge with doing this experiment is that you need to move fast enough to get some readings before the backing chamber pressure bleeds out. But if you move quickly, you are subjecting the unit to perhaps nearly 1 g and the RB sensor does act like an accelerometer. And there is some electronic filtering in the path from the sensor. From my experiment I concluded (already knowing a potential answer) the the calibration constant might reasonably be 4000 counts/pascal. I would not at all be surprised if were 5600 counts/pascal. But I am surprised if it actually is 56000 counts.

Given the difficulty of doing and interpreting the up/down test, I may have to go find a large glass bottle and syringe … :wink:



Good morning and happy Sunday.

I think the problem is that the motion you are inducing has a dominant frequency << 5 Hz.

Why 5 Hz?:

This is the instrument response of the HDF channel of the RBOOM RS&BOOM:

Screenshot from 2020-09-27 08-23-05

Notice that the amplitude is not flat to frequency. The amplitude correction factor is 56,000 counts/ Pa at 5 Hz. Applying this shifts the entire curve up.

Because you are inducing an impulse whose dominant frequency is below 5 Hz where the instrument response is not “flat”, for you to get what you want you must deconvolve the entire signal taking into account the poles and zeros in addition to the gain.

To do so, you can use ObsPy. We provide examples here and here.

Let us know what you find!


Aha - OK

I had a feeling the electronics at the front end were somehow involved.

Since the magnitude of response is down some 10 dB where I was looking - versus the calibration point of 5 Hz - my guess should have been 40-50 k counts / pascal, not 4k. Not so far off.

So I’m happy.

If I can find that data in my archives I can try to “deconvolve” the data. Perhaps when we have our first snowstorm of the year…

In the meantime, have you considered putting the RBoom microbarometer on a shake table and measure its seismic response? (along each of three axes)


1 Like

Hi Ken:

No, I have not considered that, but I do have the data already. Would you like to see it?

I frequently run my shake table experiments from 0.1 to 50 Hz, 5 minute cycles, with a max amplitude of ~500,000 counts on the geophone channel.



well - I would be curious to know if the seismic response was less along one axis than the other two axes. When paired with an RS1D, I should think that you would want that minimum response to be aligned in the “Z direction” i.e., up and down. My conclusion - from very informal testing - was that this is the direction in-line with the “spouts” of the pressure sensor. This results in the RB being mounted on its side rather than the customary orientation.



1 Like

OK – so not waiting for the first snowstorm, I installed python via Anaconda and also obspy as best I could follow. At the end, you are supposed to test it using:


I assume this is from the command line in the obspy environment.

the result complains about a missing file on drive d: - which, in fact, I do not have. What step did I miss?

obspy) C:\Users\Ken>obspy-runtests

Fatal error in launcher: Unable to create process using '“d:\bld\obspy_1593448028650_h_env\python.exe” “C:\Users\Ken\Anaconda3\envs\obspy\Scripts\obspy-runtests.exe” ': The system cannot find the file specified.

I am diving into new waters here, so be gentle …

Hello Ken,

Are you able to tell us all the steps you have followed to install anaconda first and obspy later?

The fact that it indicates a drive that you don’t have is, as you have imagined, a clear signal that something along those steps went wrong.

Hello Boomers…

Today, my RBoom almost saturated its digital amplitude range…

About 40 Km away from my RBoom location, a Rafale Jet Fighter broke the sound barrier catching up a airliner with radiocommunications troubles.
This happened just before mid-day, 10 Km away from Paris city and the sonic boom frightened a few million people living in the area… The tennis players in Roland Garros have been wondering a few seconds what could be this explosion before resuming…
Please find attached the screen capture of the infrasound signal as seen from my RBoom (RD44E).

Regards, Patrick


Thank you for the report @f5hnk!

A fantastic example of the performance of our RBOOM, and an interesting visible pattern in the saturated first wave arrival as the frequency goes upwards.

I followed the steps here

Let me clarify that I do have a drive d:

but not a directory d:\bld\obspy(etc)

what part of the software creates the \bld directory? Is it part of the install or something created “on the fly” (i.e., during execution)?


Mmm it seems quite strange since nowhere the drive d: is mentioned in the installation process. Or do you have your Anaconda installed on that drive instead of drive c:?

Nonetheless, it would be best to delete this environment and recreate everything from the start, to be sure that all will be clear.

To remove the environment first do

conda deactivate


conda env remove -n ENV_NAME where ENV_NAME should be obspy in this case

Then close and restart Anaconda, and repeat the procedure you’ve already followed. It is possible that it was just a simple case of corrupt install and this should take care of it.