Consumer for RSAM amplitude analysis

[crockpotveggies]

Wrote a module for RSAM real-time seismic amplitude measurement analysis. The module allows the user to calculate mean, median, min, and max values over a specified time window and optionally forward it to another destination via UDP.

Example from running tests:

2020-04-18 03:39:32 TESTING [RSAM] RSAM analysis up and running normally.
2020-04-18 03:39:32 TESTING [RSAM] 2020-01-30 08:26:58 [RSAM] Current RSAM: mean 16280 median 16279 min 16134 max 16456
2020-04-18 03:39:37 TESTING [RSAM] 2020-01-30 08:27:03 [RSAM] Current RSAM: mean 16280 median 16280 min 16145 max 16410
2020-04-18 03:39:43 TESTING [RSAM] 2020-01-30 08:27:08 [RSAM] Current RSAM: mean 16282 median 16284 min 16159 max 16404
2020-04-18 03:39:48 TESTING [RSAM] 2020-01-30 08:27:13 [RSAM] Current RSAM: mean 16283 median 16285 min 16163 max 16418

The user can opt to forward RSAM in a lightweight format, JSON, or CSV.

[crockpotveggies]

One thing I'd like to add here is appending the station name to the incoming data. Does anyone know how to extract that information inside the python consumer?

[iannesbitt]

One thing I'd like to add here is appending the station name to the incoming data. Does anyone know how to extract that information inside the python consumer?

Given that our UDP output doesn't include the station name, you should use the user's set station name in rsudp.raspberryshake.stn

[crockpotveggies]

Hmmm I would hesitate to combine RSAM with Alert because I think that might actually increase confusion. When I see "Alert" I immediately think the functionality should be isolated to alerts only, not an analysis. One possibility here is to rename the RSAM consumer to Statistics and open the roadmap to expanding different types of analysis beyond RSAM (such as RSEM and RMS).

I think overall the architecture of rsudp could benefit from composability: being able to chain consumer outputs to each other. I don't necessarily agree with piping messages back to the producer but just my two cents. A future version might look like this:

Producer 
    -> StatisticsConsumer 
        -> Forward
        -> Alert 
            -> AlertSound
            -> Tweet
            -> Telegram

In the meantime we could stick with a separate Statistics consumer?

[iannesbitt]

That's a really good point. I will do some thinking about reconstructing the flow so that the statistics flow down a separate path from the data. In that case they could even use different instances of the same forward module code. This is a possibility:

Producer
    -> Consumer
        -> Statistics
            -> Forward
            -> Alert 
                -> AlertSound
                -> Tweet (still need image paths for social media dissemination)
                -> Telegram (still need image paths for social media dissemination)
        -> Data
            -> Forward
            -> Plot (still need some way of letting the plot know about alerts)
            -> Write

This would require some significant changes, so might have to be put into the category of "future", so let's just work on putting out a separate RSAM module for now.

[crockpotveggies]

Sounds good, I'll get in some final changes. Can you give me instructions on how to add to the documentation?

[iannesbitt]

Documentation is built using sphinx. To build the docs, you can do the following:

pip install sphinx
cd <rsudp_directory>/docsrc
make html

With make html, docs will be built to `docsrc/_build/html' for local testing.

To build changes to the branch:

make github
git commit -a -m 'updating docs'
git push

With make github, docs will be built and copied to the docs directory.

[iannesbitt]

@crockpotveggies It looks like you added documentation to your docstrings, do you want to build and push the docs before I merge, or would you prefer I merge and build myself?

[crockpotveggies]

@iannesbitt go ahead and build the docs on your side if possible, I won't be able to get to it for another few days thanks! :)