WARNING (norm_resp): computed and reported sensitivities differ by more than 5 percent. Execution continuing.

[Larusrafn]

on windows, environment downloaded by executing the win-install-rsudp.bat and then excecuted with win-start-rsudp.bat, this error shows when running if "deconvolve" is set to true either on the plot or alert setttings (or both):

WARNING (norm_resp): computed and reported sensitivities differ by more than 5 percent. Execution continuing.

this is constantly repeated causing fast scrolling of the console window.

[iannesbitt]

This is probably not just a Windows-specific issue, as it seems like something that stems from obspy or scipy. I will check to see if there's a way to suppress this output, or better yet figure out why it is being printed.

[Larusrafn]

i can recreate this at will... and can provide log files if you need them. just tell me what ones you want.

[iannesbitt]

Can you attach /tmp/rsudp/rsudp.log, and also copy/paste your console output? I'm curious if it gets written to the log or not (if it's from ObsPy I suspect it may only be a console output)

[iannesbitt]

It would also help to attach your settings file (most likely at ~/.config/rsudp/rsudp_settings.json) and/or to know what your station name is.

[Larusrafn]

My station is AM.R075C located in iceland. I downloaded fresh from master, so im running version 1.0.3. here are the log file, console output and sanitized rsudp settings file (to protect the innocent....) console-output.txt rsudp.log rsudp_settings-json.txt

[Larusrafn]

I also see that the STA/LTA readings are much higher when deconvolve=true on the "alert" setting, for the same visual level of background noise on the plot: deconvolve off: 2021-10-29 23:06:22 [Consumer] Exiting.2.4; Current max STA/LTA: 0.1391 deconvolve on: 2021-10-29 23:08:19 [Alert] Threshold: 2.4; Current max STA/LTA: 1.5395

its almost like its off by a placement of decimal point

[iannesbitt]

Ah yes, good call with the sanitization.

I also see that the STA/LTA readings are much higher when deconvolve=true on the "alert" setting, for the same visual level of background noise on the plot

That's actually normal. The STA/LTA value is highly dependent on averages, and the process of deconvolution should change the short term and long term averages a bit for most sensors. The reason you don't see any difference on the plot is because the plot thread's stream is independent of the alert thread's stream and so on. Each thread has its own stream of data, for both thread safety and because it's often useful to manipulate them separately.

The problem you're describing in this issue is an underlying obspy issue and I can't recreate it at the moment. I may have time tomorrow. In the meantime, can you send me the output of

pip freeze

from the rsudp conda environment?

[Larusrafn]

I ran 2 streams for fun to side by side compare the rsudp consoles and spectrograms (feeding the second via new datacast port on the raspberry shake and using another config file).. and the difference is a lot... like you can see on this screenshot. while one has sta/lta of 0.2099 the other has sta/lta of 1.5915. this is an order of magnitude more.... can this really be the expected behavior?

here is the output of pip freeze: PS C:\earthquake\rsudp-master> pip freeze brotlipy==0.7.0 certifi==2021.10.8 cffi @ file:///C:/ci/cffi_1625831756778/work charset-normalizer @ file:///tmp/build/80754af9/charset-normalizer_1630003229654/work conda==4.10.3 conda-package-handling @ file:///C:/ci/conda-package-handling_1618262410900/work cryptography @ file:///C:/ci/cryptography_1635366712888/work idna @ file:///tmp/build/80754af9/idna_1622654382723/work menuinst==1.4.16 pycosat==0.6.3 pycparser @ file:///tmp/build/80754af9/pycparser_1594388511720/work pydub==0.25.1 pyOpenSSL @ file:///tmp/build/80754af9/pyopenssl_1635333100036/work PySocks @ file:///C:/ci/pysocks_1605307512533/work pywin32==228 requests @ file:///tmp/build/80754af9/requests_1629994808627/work ruamel-yaml-conda @ file:///C:/ci/ruamel_yaml_1616016898638/work six @ file:///tmp/build/80754af9/six_1623709665295/work tqdm @ file:///tmp/build/80754af9/tqdm_1635330843403/work urllib3==1.26.7 win-inet-pton @ file:///C:/ci/win_inet_pton_1605306162074/work wincertstore==0.2

[iannesbitt]

Hi @Larusrafn,

can this really be the expected behavior?

Yes, although I think I understand your confusion. There are a couple of things at work here that I need to unpack to explain this.

First, I think you might be misunderstanding the data plotted by rsudp. The streams rsudp shows in the plot are automatically detrended, regardless of whether they are deconvolved or not. So what you are seeing in the plot has been stripped of its bias, and therefore is not a pure representation of the raw data. The reason we chose to do this is 1) the spectrogram representation requires detrending...if the stream has any bias whatsoever it is counted as very high powered long-period noise in the frequency spectrum and therefore renders the spectrogram meaningless, and 2) that representing a fully raw stream but a detrended spectrogram would require the plot module to maintain two separate streams. We thought it would just be easier and less confusing to show both of them as detrended data and therefore just maintain the single stream.

In my testing the recursive STA/LTA we use gave larger values for the raw—non-detrended—data than for detrended data. (As an aside, I originally set the threshold to 1.7 before deconvolution was even part of rsudp's functionality.) I think the difference is just a function of the fact that the two means are relatively high prior to detrending. The STA/LTA ratio is a dimensionless number that is completely reliant on the data being fed to it, so for example it would have to be tuned completely differently for a longer period instrument. Hopefully this answers your question.

---

Additionally, it doesn't look like your pip freeze worked on its own, I'm guessing because the conda environment wasn't active. Can you try the following instead?

conda activate rsudp
pip freeze

[iannesbitt]

There's also quite a lot of writing about the STA/LTA trigger mechanism. From GFZ Potsdam:

• Lengthy discussion of STA/LTA parameter settings
• Illustrated discussion of a few different phase triggers

[Larusrafn]

thank you for this info. i am new at this level of earthquake monitoring although i have been lucky enough to be born in a very active region of the world and being thrilled by all things nature, including geology, quakes, weather, etc..

i did not know that i had to activate the environment through a specific conda promtp, but i found it (thanks google).. so here is the output:

(base) C:\Users\lalli>
(base) C:\Users\lalli>
(base) C:\Users\lalli>conda activate rsudp

(rsudp) C:\Users\lalli>pip freeze
APScheduler==3.6.3
backports.zoneinfo==0.2.1
brotlipy==0.7.0
cachetools==4.2.2
certifi==2021.10.8
cffi @ file:///C:/ci/cffi_1625831764494/work
charset-normalizer @ file:///tmp/build/80754af9/charset-normalizer_1630003229654/work
cryptography @ file:///C:/ci/cryptography_1635366713676/work
cycler==0.10.0
decorator @ file:///tmp/build/80754af9/decorator_1632776554403/work
future==0.18.2
greenlet @ file:///C:/ci/greenlet_1628888257991/work
idna @ file:///tmp/build/80754af9/idna_1622654382723/work
importlib-metadata @ file:///C:/ci/importlib-metadata_1631916842152/work
kiwisolver @ file:///C:/ci/kiwisolver_1612282618948/work
lxml @ file:///C:/ci/lxml_1616443391272/work
matplotlib==3.1.1
mkl-fft==1.2.0
mkl-random==1.1.1
mkl-service==2.3.0
numpy==1.16.4
oauthlib==3.1.1
obspy @ file:///D:/bld/obspy_1628034511127/work
olefile==0.46
Pillow==8.4.0
pycparser @ file:///tmp/build/80754af9/pycparser_1594388511720/work
pydub==0.25.1
pyOpenSSL @ file:///tmp/build/80754af9/pyopenssl_1635333100036/work
pyparsing @ file:///home/linux1/recipes/ci/pyparsing_1610983426697/work
PySocks @ file:///C:/ci/pysocks_1594394709107/work
python-dateutil @ file:///tmp/build/80754af9/python-dateutil_1626374649649/work
python-telegram-bot==13.7
pytz==2021.3
pytz-deprecation-shim==0.1.0.post0
requests @ file:///tmp/build/80754af9/requests_1629994808627/work
requests-oauthlib==1.3.0
rsudp @ file:///C:/earthquake/rsudp-master
scipy @ file:///C:/ci/scipy_1597686737426/work
six @ file:///tmp/build/80754af9/six_1623709665295/work
SQLAlchemy @ file:///C:/ci/sqlalchemy_1626948528806/work
tornado @ file:///C:/ci/tornado_1606935947090/work
twython==3.9.1
typing-extensions @ file:///tmp/build/80754af9/typing_extensions_1631814937681/work
tzdata==2021.5
tzlocal==4.0.2
urllib3==1.26.7
win-inet-pton @ file:///C:/ci/win_inet_pton_1605306165655/work
wincertstore==0.2
zipp @ file:///tmp/build/80754af9/zipp_1633618647012/work

(rsudp) C:\Users\lalli>

and the package info:

(rsudp) C:\Users\lalli>conda list rsudp
# packages in environment at C:\Users\lalli\miniconda3\envs\rsudp:
#
# Name                    Version                   Build  Channel
rsudp                     1.0.3                    pypi_0    pypi

[Larusrafn]

.........and thank you for excellent support for a newbie like myself :)

[iannesbitt]

No problem! I'm no longer affiliated with RS but I am very much still on good terms with them, and I maintain this software because I have a strong attachment to it from spending so many hours working on it.

I'm curious as to why obspy appears to be built from source and not pinned to a specific version...can you run the following command from your rsudp environment:

python -c 'import obspy; print(obspy.__version__)'

[Larusrafn]

I had to change the command to double quotes, else it got syntax error. but herre:

(rsudp) C:\Users\lalli>python -c "import obspy; print(obspy.__version__)"
1.2.2

[iannesbitt]

Interesting. Can you run the rs-test command and see if it happens in that mode as well?

[Larusrafn]

Is deconvolve set to true by default in the test phase? the error does not show in rs-test, see output in attached file. Maybe this is something new in the raspberry shake data stream? i am running 0.19.

rsudp_bug-ticket_26-rs-test-output.txt

[Larusrafn]

here is a wireshark pcap of the packets sent from my raspberry shake unit on port 8888 if that helps with debugging rsudp_bug-ticket_26-RS-pcap-udp-port-8888.zip

[Larusrafn]

hm. i think I got something more. look at the difference of the velocity and acceleration scale on the live (left) and the test (right). the live is in km/s velocity and hundreds of m/sec2 while the test is in um/s velocity and tens of mm/sec2.... how come?

[iannesbitt]

Ok, that's weird but I think I at least know the nature of the problem. Can you check your shake settings to make sure you have this RS geophone setting set to "Yes"?

[Larusrafn]

this is set to yes in my rs.

[iannesbitt]

Can you set the writer to record a minute or so of your data and send it to me?

"write": {
    "enabled": true,
    "channels": ["all"]},

[iannesbitt]

I think I've narrowed the problem down to the format of the inventory that RS provides for your station. There is a section missing from the inventory XML which provides poles and zeroes, a critical part of calculating response. I will contact them about this.

[Larusrafn]

thank you. in the mean time, here is ~5 mins of output... i have also done everything i can think of to test fixing this, including changing my locale in the computer and completely wiping miniconda from the computer and start from scratch.. :) data.zip

[iannesbitt]

Don't worry, your locale and miniconda are fine!

[Larusrafn]

the only thing i can think of as a cause for this from my doings is that i started a datacast and played around with the rsudp for a day or two before I started the data sharing... if that has something to do with this document creation.

[Larusrafn]

the Shakenet has stopped displaying my RS output this morning and it is shown as black (not available) now. Shutting my RS off and powercycle it does not fix the issue.

It still says its on,

are we still waiting for response from RS team about the xml file?

[iannesbitt]

Hi Larus, it looks to me like your station is online again. I talked to the RS folks not long ago and they are working on the inventory issue. Thanks for your patience.

[Larusrafn]

Thank you for all your help, i will wait patiently :) the shake is working, it took a long time (+2 hours i think) to show up again in the shakenet after the reboot. it seems to work fine except for the display weirdness... it correctly detected a large quarry blast 7 km away as 1.1M earthquake today :)

[iannesbitt]

Good to hear. The inventory problem should be fixed in the next few hours, if it's not already.

Cool captured blast!

Yeah, the plot distance ratios can get weird when the window size changes too much. It seems like the acts of edge snapping and maximizing the window have the worst effects, and I haven't figured out how to correctly preserve the distance ratios between the plot elements when that happens. It seems to fare better when the window size changes more slowly by dragging the window edge. There is a way to start the plot in a fullscreen window (fullscreen: true,), and also in kiosk mode (i.e. occupying the entire screen, without window borders and titlebar, which can be done with kiosk: true,). If you are trying to show the plot on the side of a screen with other windows visible, it may make sense to start the plot in fullscreen windowed mode and then drag the window edges to change the size from there.

[iannesbitt]

Sorry I have that backwards: if you start in fullscreen and then resize, the size jump the window makes isn't handled correctly by matplotlib. However if you start in non-fullscreen windowed mode, the gradual drag-resize should work.

[Larusrafn]

confirmed. the issue is fixed. velocity and acceleration show correct values and the errors on the console are gone. thank you for all your help!

[iannesbitt]

Of course! Thanks for your patience.