See also: the Raspberry Shake Forum where you can easily search the archives for questions similar to your own.
Question: The Shake box seems to come with some nice trim screws to set it level. How though is the unit meant to be coupled to the ground/concrete/slab/table…? The last few earthquakes I’ve experienced here in New Zealand would of sent the Raspberry Shake bouncing off the table or sliding over floor which means it will not actually be recording what it is meant to? How is it proposed to couple it to the horizontal surface?
Answer: Shake does not need to be “anchored”.
Raspberry Shake is a weak motion device, like most seismometers are. It is designed to measure sub-micron movements. It probably completely clips between 0.1 and 0.2 g.
If during an earthquake objects are in the air then surely 1 g has been exceeded. Just yesterday I was watching youTube videos of the last New Zealand earthquake and yes things were moving. Shake and any other seismometer would be totally saturated and the data would be useless even if they were anchored.
Seismologists use accelerometers which have a range above 1 g commonly set to 2 g and can be set to 4 g. These devices are anchored. In a Class A seismic installation you would have a seismometer, and accelerometer that goes to DC and a GPS. This would allow for the huge dynamic range that you will get in a large earthquake. The accelerometer to DC and the GPS would allow you to see the displacements that a velocity sensor like the Shake will not show.
Answer: This is a good question and one that is tossed around here at Raspberry Shake. Geophones are made by lots of companies and in lots of natural frequencies and cases and coil types. We think that the geophone used in Raspberry shake will have over 95% of it output out to about three degrees. A quick and dirty test of the undamped output of the Raspberry Shake’s 4.5 Hz geophone was performed. We did the test at 10 Hz to get away from the amplification of the resonant frequency. We moved the geophone 1 mm. 1mm at 10Hz is strong shaking. From 0 to 3 degrees of tilt we could not see any significant difference in the output. It was not until 6 degrees that we could see a change and not until 15 degrees that the output was meaningless.
We can definitely say that if the leveling bubble is mostly within the little circle on the level built into the acrylic box, that things are ok. From the test we have done, I think that the leveling bubble we provide will achieve the +/- .5 Degrees as long as the leveling bubble is centered in the circle.
Later, one of our backers, Brett, responded: “I did a quick test to check the leveling bubble sensitivity. It took about one turn of the leg screw located on the center line to move the leveling bubble from centered to be solidly touching the black ring. That’s 0.8mm over 123.5mm, the perpendicular distance from that screw to a line between the other two legs. That ratio is 0.00648 and taking the ArcSin = 0.37 deg. of tilt, which is slightly better than you suggest. Probably the biggest factor will be how well the geophone guts are aligned with the leveling bubble. Super leveling is not going to be an issue.”
IP addresses can either be “DHCP”, that is “D”ynamically assigned, or “Static”. Most routers today dynamically assign IP addresses. That means that every time a computer like the Raspberry Pi is connected it is given an IP address. It can be the same IP address as previously assigned or a new one. The connection is time limited. Some routers set it to a day or so, some months and still others many years. So, depending on the router settings, the connection will be released and reconnected after a certain time window. On some routers it is possible to change length of the time, on others not. For example at a university where many people come and go, the time window is set to shorter time so that the IP address can be recycled. At home where you have fewer computers, you would obviously prefer a longer time window. The solution around this problem is to set a Static IP address. See here for instructions: Static IP
Question: When I start Shake #1, it takes the DNS name
rs.local. Then, when I start Shake #2, it takes over the DNS name
rs.local and kicks Shake #1 to
rs-2.local. What is happening and how can I stop it?
Answer: This is a complex one and can only happen on certain networks (generally, those that use small or medium business hardware). Let’s start by leaning about the two protocols that smart switches usually have. Then we can take a look at “what’s happening,” then finally how you can fix it.
Protocol 1: RSTP
RSTP makes sure there are no loops or ambiguities on the network. The switch will not forward any packet from a port that just came up until its tests are done. Here’s a good link that explains RSTP in full.
Protocol 2: Avahi/Bonjour
This protocol is responsible for searching for, assigning, and keeping track of DNS names on many modern networks.
Connection type 1: IPv4
The IPv4 link needs to negotiate with a DHCP server in order to get an address. This takes a short but significant amount of time.
Connection type 2: IPv6
The IPv6 link does not need negotiation of local-link addresses like IPv4 does. It just picks one of many millions of addresses and then can send packets right away.
Shake 1 is already booted and it has the hostname
When the first link on Shake 2 becomes ready, Avahi immediately sends a broadcast packet that says “hello! does anyone own rs.local?” with any connection available. Since IPv6 is generally the first connection to become available, the Avahi request is sent via this connection. IPv4 is not ready at this point, since it is still negotiating its address with the DHCP server.
At this moment the switch (with RSTP turned on) is not forwarding packets to Shake 2 yet. It “checks” that everything is ok with network and that there are no ambiguities.
The result is that nobody sees the “hello” packets sent by Shake 2. So Shake 2 decides there is no
rs.local on the network and announces its name (
rs.local) to the network. At that moment, the IPv4 link becomes ready (i.e. the switch now forwards packets from Shake 2). Shake 1 sees someone took its name and automatically assigns itself a new name
How to fix it:
There are a few ways to potentially fix this issue:
By disabling IPv6. You can do this by editing the file
sudo nano /etc/sysctl.conf
add the following lines to the end of the file:net.ipv6.conf.all.disable_ipv6=1 net.ipv6.conf.default.disable_ipv6=1
Then restart the Shake. The DNS name should now “stick” once assigned.
Manually change the DNS name. You can do this by editing the file
sudo nano /etc/avahi/avahi-daemon.conf
Modify the following line and replace
rswith the DNS name of your choice. It should have no spaces or special characters except minus (
Then restart the Shake. Your shake should now be visible at
nameyouchose.local. If you lose track of what you’ve named your Shake, you can Find your Raspberry Shake’s IP with Fing.
Disable RSTP on your switch. Since this is device-specific, we can’t help you. However, a google search for “Disable RSTP on [your device’s make and model]” may help.
The schematic for Shake is not available. Much of the software is open. Our reason for not making the schematic available is that if we made the hardware open and the firmware that went with it, we would see Raspberry Shake on Alibaba before the Kickstarter campaign was even over.
We align ourselves in many ways with the folks at Pololu when they make this statement about open hardware: See article here. Pololu put a huge amount of work in writing that piece, long but worth the read.
sps = samples per second on all channels
The RS1D, RS3D, RS4D and RS&BOOM have the same capabilities for detecting Earth motion in the vertical dimension. The RS3D replicates these abilities in the horizontal dimensions, providing the user with a fuller view of Earth motion in all 3 dimensions. The difference between the RS1D and the RS4D is that the RS4D has a 3 dimensional accelerometer built into the board. This is interesting for people who live in earthquake zones where the strong motion might be enough to saturate the vertical sensor. With the accelerometer, the Earth motion would remain on scale with the added benefit of being able to detect lateral motion as well.
This is because the RPi computer only has one serial port (Rx/ Tx) connection. See GPIO pins.
The short answer: if it’s below about 75 ℃, probably not.
The CPU temperature can be monitored on the web front end. Depending on the case it’s installed in, the ventilation, and the ambient air temperature and humidity, the CPU will probably run anywhere from about 45 to 65 ℃. The RS3D, RS4D, and RJAM typically run hotter than the RS1D. Waterproof enclosures will be slightly hotter than the standard acryllic ones due to lack of air exchange.
If the CPU temperature goes above 80 ℃, the system will throttle the performance and you may notice data gaps and connection problems, possibly requiring a restart. It is a good idea to place the Shake in a relatively cool location without large temperature swings.
If you plan on mounting the Shake in a hot location, it may need some sort of passive cooling. Active cooling (fans) typically generate noise that may be undesirable for your use case. Generally, giving the Shake some breathing space and avoiding packing it in with insulation (unless it’s being installed in a very cold environment) is a good idea.
Default ssh password: shakeme
See also: How to change your ssh password.
See our: License
Additional note: All Raspberry Shakes purchased during the Kickstarter campaign are exempt from the license requirement.
We do not recommend updating the Raspberry Pi’s OS The problem with updating the OS, without regard to the operating environment it supports, is that the possibility exists for the update to break some instance of infrastructure on which the executing system relies. It is possible that the Raspberry Shake unit will simply stop functioning and you won’t know why. Rather, it is preferred that the maintainer of the system fully understand the implications of any OS update on the system itself before allowing such an update to take place. Only once an OS update has been fully vetted (vs. all activities it is required to support) should it then be rolled out to individual units in the field. For more details see: Ready, Set, Get Hacked! Security and Raspberry Shake.
Please send an email to the Feedback section of the Community Forum list with the subject: “Bug Report (<Tool>): <some summary message here>”
All models of Raspberry Shake, including the RS1D, RS3D, RS4D, RBOOM, RS&BOOM and RJAM use the same software.
In short: we intentionally obscure publicly-reported station locations for user privacy reasons.
The longer and more technical answer of why we can do this:
The obscured locations we expose to the public are not obscured enough to effect earthquake solutions, as seismic waves travel anywhere from 2-8 km/s near earth’s surface. Even the best global seismic velocity models are not great at incorporating regional velocity changes and therefore seismic wave arrival times can vary by many hundreds or thousands of milliseconds, especially for regional events where regional velocity can differ significantly from the global models. Seismology is a very imperfect science, and Earth is a very imperfect place to study seismic wave propagation because surface and crustal material velocities vary widely and we know so little about how they do. Depending on the geologic material (clay, sand, granite, basalt, etc) seismic waves can change speed very frequently, and they typically do so without our knowledge. Because of this, introducing a few hundred meters of randomly determined variation is a relatively small source of error on the earth-scale of things.
We’ve gotten this question a lot, and it can depend on what features you have enabled, and whether you are simply forwarding data, or also accessing the Shake via SWARM, FileZilla, or a Seedlink/Earthworm/Wave Server client.
Below, we show the calculations we use for figuring out the maximum and average data transfer rates for a Shake 4D (4 channels) as of version 15 of the software.
Max data / second: = number of bytes for headers + number of bytes for data points chn = total number of channels dpf = data packet frequency, i.e., number of data packets / second dph = data packet header size sps = sample rate, as samples / second bdp = max bytes / data point = chn * dpf * dph + chn * sps * bdp = 4 * 4 * 80 + 4 * 100 * 11 = 1280 + 4400 = 5680 bytes / second Max data per day: = 5680 * 86400 = 490752000 bytes = 468 MB Average data per day: (assuming 5 bytes / data point): = 270MB / day / 100Hz 4D Max data per month: 468 MB * 30 days = 14040 MB/mo Average data per month: 270 MB * 30 days = 8100 MB/mo
These calculations are scalable to any of our instruments, depending on the number of channels. For example, for a 1D or Boom, divide these final numbers by 4 (2-3.5 GB/mo). For a 3D, multiply by 0.75 (6-10.5 GB/mo). For a Shake&Boom, divide by 2 (4-7 GB/mo).
As stated above, if the data transfer rates you calculate are higher than these, then there is some other process using data. Typically, there is no need to worry about data consumption unless you are on a cellular network that regulates the transfer of data. The Shake uses far less than, say, streaming video services. If you are worried about data usage however, check the logs for connections to the wave server and ensure that other running programs are turned off.