Raspberry Shake Coding

[Dylan Mayes - Mines]

Hello everyone! I am new to the Raspberry Shake community. I am a Geophysics student at Colorado School of Mines and I'm doing a capstone project with the shake. The dilemma I'm running into is for the project, we must use some sort of coding involved with our RPi or Shake and/or any sensors or LEDs. 

I know the shake is "headless" and information is accessed through the internet, but does anyone have any suggestions on a way to do some coding with the shake? 

Just an idea: It would be awesome if I could use an LED to light up when the shake detects movements over a certain amount and potentially use some data visualization with python to interpret some data!

[Branden Christensen]

Good morning Dylan and welcome to the community!

You will find useful programming tools here: 

https://manual.raspberryshake.org/developersCorner.html#developer

Branden

On Mon, Apr 2, 2018, 23:53 Dylan Mayes - Mines <dylanjacq...@gmail.com> wrote:

Hello everyone! I am new to the Raspberry Shake community. I am a Geophysics student at Colorado School of Mines and I'm doing a capstone project with the shake. The dilemma I'm running into is for the project, we must use some sort of coding involved with our RPi or Shake and/or any sensors or LEDs. 

I know the shake is "headless" and information is accessed through the internet, but does anyone have any suggestions on a way to do some coding with the shake? 

Just an idea: It would be awesome if I could use an LED to light up when the shake detects movements over a certain amount and potential use some data visualization with python to interpret some data!

--
Some useful links:
 
Manual: http://manual.raspberryshake.org/
Do It YourSelf Page: http://raspberryshake.org/do-it-yourself
Shop: https://shop.raspberryshake.org/
Website: http://raspberryshake.org/
 
Instagram: https://www.instagram.com/raspishake/
Facebook: https://www.facebook.com/raspishake/
Twitter: https://twitter.com/raspishake/
Hashtag: #rasperryshake, @raspishake
DOI: https://doi.org/10.7914/SN/AM
---
You received this message because you are subscribed to the Google Groups "RaspberryShake" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raspberryshak...@googlegroups.com.
To post to this group, send email to raspber...@googlegroups.com.
Visit this group at https://groups.google.com/group/raspberryshake.
To view this discussion on the web visit https://groups.google.com/d/msgid/raspberryshake/d216a21a-149d-45c3-8d0e-a82cbce92278%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Angel Rodriguez]

Hi Dylan,

While the shake is headless and the data is mostly available over the internet there are some tools that might allow you to do things that would not be tied to the data stream we mostly use.

The shake has a "raw" UDP data stream that you can use locally or over the internet, check out the manual here.

https://manual.raspberryshake.org/udp.html#udp

You can use the data stream in real-time in any way want.  This stream can be accessed right on the RShake and there are free GPIO pins available on Pi version with the 40 pin header.

I am presently working on one project that is very close to what you described but that does not stop you from doing it also.  I will be computing PGV and PGA and making LEDs come to life based on those calculations.

I suspect that some of the list members can come up with project ideas.  I would be interested in following whatever project you use and to help if I can.

Saludos,

Angel

Check out the new Kickstarter campaign for Raspberry Boom! Funded in less than a minute.

https://www.kickstarter.com/projects/1158786437/raspberry-boom-atmospheric-monitor-the-weather-and?ref=59fwnb&token=f41706a2

When you have 27 minutes to kill take a listen to Angel at educational and citizen seismology workshop held at the Geological Society in London February 2018

https://www.youtube.com/watch?v=waeui99X0mw

WhatsApp +507-6747-0012

On Mon, Apr 2, 2018 at 11:53 PM, Dylan Mayes - Mines <dylanjacq...@gmail.com> wrote:

Hello everyone! I am new to the Raspberry Shake community. I am a Geophysics student at Colorado School of Mines and I'm doing a capstone project with the shake. The dilemma I'm running into is for the project, we must use some sort of coding involved with our RPi or Shake and/or any sensors or LEDs. 

I know the shake is "headless" and information is accessed through the internet, but does anyone have any suggestions on a way to do some coding with the shake? 

Just an idea: It would be awesome if I could use an LED to light up when the shake detects movements over a certain amount and potential use some data visualization with python to interpret some data!

--
Some useful links:
 
Manual: http://manual.raspberryshake.org/
Do It YourSelf Page: http://raspberryshake.org/do-it-yourself
Shop: https://shop.raspberryshake.org/
Website: http://raspberryshake.org/
 
Instagram: https://www.instagram.com/raspishake/
Facebook: https://www.facebook.com/raspishake/
Twitter: https://twitter.com/raspishake/
Hashtag: #rasperryshake, @raspishake
DOI: https://doi.org/10.7914/SN/AM
---
You received this message because you are subscribed to the Google Groups "RaspberryShake" group.

To unsubscribe from this group and stop receiving emails from it, send an email to raspberryshake+unsubscribe@googlegroups.com.
To post to this group, send email to raspberryshake@googlegroups.com.

[John Beale]

Angel: I was interested to try out the UDP stream on my Pi. I gather this is available in version 0.8 of the software(?)  I could not open the UDP stream on my R-Shake, although it is online and working. The example Python program gave me: "socket.error: [Errno 99] Cannot assign requested address"

When I checked my locally-hosted web page I found that I am still on Version 0.10 ?  How can I upgrade?  Or is there a different version number I should be looking for?

Raspberry Pi Model	:	3 Model B
System Status	:	RUNNING
System Version	:	0.10
Local IPv4	:	192.168.1.77

As far as I can tell, UDP port 8888 is definitely closed on my R-Shake, as seen from a different R-Pi on the same LAN:

pi@rp48:~ $ sudo nmap -sU -p U:8888 192.168.1.77

Starting Nmap 7.40 ( https://nmap.org ) at 2018-04-03 07:50 PDT

Nmap scan report for 192.168.1.77

Host is up (0.00047s latency).

PORT     STATE  SERVICE

8888/udp closed ddi-udp-1

 

[Richard]

hi john,

that's not v0.1 you're on, that's version 10, i.e., you are on the latest release.  the error you see results when trying to bind to the localhost.  can you send along your log files (downloadable from the front-end interface, Actions screen) so i can have a look at what might be going wrong?

thanks,

richard

[John Beale]

Richard: Thanks for the prompt reply. I will look for the log file when I get back home. Note I was trying to access port 8888 from a different Raspberry Pi on the same LAN. I modified the example Python code to point to my R-Shake's IP number 192.168.1.77 but is this port available only from the same machine (localhost)? If so, that would explain why my test did not work. If I have to do this while logged into a shell on the R-Shake itself, I guess I will have to try to remember the password.

[Richard]

ah, yes, that's the problem.  The sample program will only work when executed on the Shake Pi.  This is because the data-producer program defaults to sending the data to port 8888 on the same computer only.

As well, you are trying to bind to a port on a different computer, this is not possible.  Rather, you must configure the Shake to forward its data to the destination computer intended to read the data.

If you want to send the data to another computer on your LAN, then, you do this by creating a configuration file based on the template file UDP-data-streams.conf.tpl, located in /opt/settings/user.  Copy this to file named UDP-data-streams.conf, in the same directory, and edit it accordingly.  You can specify as many other machines to be destinations as you would like, as well as specifying any port you like for each.  Once the changes have been made, the data-producer program will pick up the modifications (within 10 seconds) and immediately begin delivering the data to the newly configured machines and ports, i.e., no restart of the system is necessary.

Then, on the destination computer, if your port is not 8888, modify the python program shake-UDP.py, the port number only, (leave the host = "" ), and execute as:

> python shake-UDP.py

let us know how you get on,

richard

[John Beale]

Excellent! Against all odds, I remembered the unique password I set on the R-Shake over a year ago. I ssh'd in and followed these instructions. Sure enough now the python program on the other machine prints out the data, 1 per second as I have the original single-axis Shake. Very nice!

{'SHZ', 1522809952.475, 106, 324, 337, 228, 321, 396, 341, 207, 220, 615, 789, 302, 29, 54, 74, 437, 590, 368, 157, 274, 407, 246, 107, 159, 67, -189, -91, 175, 280, 355, 303, 309, 462, 385, 148, -68, -354, -435, -69, 198, 510, 512, 234, 267, 245, 228, 190, 89, 393, 706}

{'SHZ', 1522809953.475, 339, 26, 120, 6, -66, 204, 238, -142, -51, 270, 604, 738, 671, 608, 491, 316, 162, -68, 19, 359, 553, 296, 121, 268, 359, 214, 146, 124, 130, 266, 387, 336, 383, 239, 158, 386, 546, 501, 340, 194, 106, 205, 242, 4, -128, 128, 244, 252, 447, 469}

[John Beale]

Here is a slightly different version of the example Python program. This prints out the data elements, one per line for convenient processing. 

It includes a header line with the start time of the first sample, all other lines are simply the data samples.

This one only works as far as I know with the single-channel Shake. Sample output:

# 'SHZ' Wed, 04 Apr 2018 04:19:43 UTC

 679

 446

 331

 251

 90

 1

 86

... and so forth.

#!/usr/bin/python

# Print out data stream from 50 Hz single-channel Raspberry Shake

# See also: https://manual.raspberryshake.org/udp.html#udp

# https://groups.google.com/forum/#!topic/raspberryshake/vZOybDRDpHw

import socket as s

import time

host = ""                   # can be blank for localhost

port = 8888                             # Port to bind to

sock = s.socket(s.AF_INET, s.SOCK_DGRAM | s.SO_REUSEADDR)

sock.bind((host, port))     # connect to this socket

def plist( list ):

  "Print out elements of list, one per line"

  for elem in list:

    print elem

data, addr = sock.recvfrom(1024)    # wait to receive data

elems = data.translate(None, '{}').split(",") # remove brackets, separate elements

channel = elems[0]                  # first elem is channel, eg. 'SHZ'

tstamp = time.strftime("%a, %d %b %Y %H:%M:%S UTC", time.gmtime(float(elems[1])))

print "# " + channel + " " + tstamp

plist(elems[2:])                    # output each data point, 1 elem per line

while 1:                                # loop forever

    data, addr = sock.recvfrom(1024)    # wait to receive data

    elems = data.translate(None, '{}').split(",") # remove brackets, separate elements

    plist(elems[2:])                    # print each data point

# ===============================================================

[John Beale]

I have run my code for a few days now, getting one packet every second from my 50Hz 1D Shake.  I find that about once every 40 minutes, my Shake sends a packet containing only 49 data points instead of 50 points. This had some consequences to my simple processing algorithm so I'll need to have it adapt to variable data lengths.

 

It seems that the Shake code sends one packet every second per the Raspberry Pi system clock as steered by NTP, but the actual ADC sampling rate is controlled by a separate free-running oscillator on the ADC that is not locked to NTP (?)

[Larry Cochrane]

Hi John.

This is normal. On my 1D I see 51 samples every once in a while. As you expected its do to the clock driving the ADC chip. On your 1D the clock is running a little slow so sometimes you will see 49 samples. The clock on my 1D is running a little faster so sometimes  I see 51 samples.

Regards,
Larry Cochrane
Redwood City, PSN.

[Richard]

hi john,

the discrepancy in data packet sizes you are seeing is indeed the adjustment necessary to keep the clocks in sync.  in fact, it can also happen that you can get an *extra* sample (51 in your case) instead of missing a sample, depending on which clock is faster.

in addition to an adjustment being made in regards to the number of sample, the timestamp is also adjusted, guaranteeing that there will be neither a gap nor an overlap.  that is, the number of samples expected for the time span defined by the timestamps of the current and next data packets will always be correct.

so instead of expecting a constant number of data points per second / packet, you should expect a mathematically consistent number of data points per time span defined by the timestamps of the packets themselves.

hope this helps,

richard

(and excellent deductions, btw...)