7. Testing and demoing rsudp¶
rsudp includes a small piece of software meant to test the ability to function and process seismic data. This could be useful if you are looking to demonstrate rsudp’s functionality to someone, perhaps a classroom of students, or if you need to test the core functionality like alerts and sounds.
Testing can also be useful for discovering whether or not a specific piece of data will trigger the alarm using settings from a custom settings file. For instructions on how to do that, see Settings during testing and Using your own data below.
The testing functions are useful for figuring out local problems. That is, the testing capabilities of rsudp are meant to discover whether or not the software can feed data to itself and process it.
If you can run this testing program without any problems but you are having issues getting the software to see data from your own Raspberry Shake or boom, see the Troubleshooting page.
7.1. Using the testing functionality¶
The testing modules of this software are designed to read a small data file from disk and send its contents to the test port one line at a time. The program functions essentially as it would if it were receiving remote data, but instead it is feeding data to itself.
This means that you can demo the software even if you don’t have a Raspberry Shake, or even use the testing functionality to check whether or not an arbitrary piece of archival Raspberry Shake data will trigger an alarm in the software.
Once you have done that, the test command
rs-test will become
rs-test to watch earthquake detection in
action. The test will last about 120 seconds, over which time
various bits of functionality will be tested, including ports,
directory permissions, internet, processing routines,
alert functionality, sound-playing capability, and more.
It does test whether it can see the internet at large, and whether it can send data to its own port (we’ve chosen 18888 as a test port). However, it does not test the ability to receive data from a remote shake. If you are having trouble with that, please see the Troubleshooting page.
7.2. Settings during testing¶
Default settings are slightly different during testing than they would
ordinarily be. Find a summary of what gets changed at
To specify a settings file to use, use the
-s flag. This is the same
as it would be if you were telling the
rs-client to start with a
specific settings file. Usage looks like this:
rs-test -s custom_settings.json
If you need to dump and edit a custom settings file to test with, you can use the client’s settings dump:
rs-client -d custom_settings.json
7.3. Data flow during testing¶
During testing, the typical data flow as depicted in
Program architecture and flow must be created artificially.
So, instead of getting data from the Raspberry Shake as usual,
rsudp.t_testdata.TestData thread reads a file and
sends the individual lines in that file to the data port.
The Producer then reads that data and data flow through the rest
of the architecture continues as normal.
7.4. Testing your own modules¶
Read about adding testing capabilities to new modules in Testing your module.
7.5. Using your own data¶
Included in this software is a function that will convert small seismic data files (basically anything that obspy can read) to the UDP packet format required by rsudp.
This function is documented at
and it is integrated into the testing script. You can tell the testing
script to convert and use a miniSEED file on disk by doing the following:
rs-test -i test.mseed
This will create a text file named
test.mseed.txt in the same directory
which will be used to feed data to the producer during testing.