Based on this USGS information I need to ensure a sufficiently high sampling rate to ensure the data collected is useful. Most earthquake waves appear to have a frequency of < 20Hz so taking Nyquist in account I need to be sampling at least at 40Hz.
In a tight loop doing nothing but communicating with the accelerometer I read X,Y & Z acceleration values then averaged the results over 10 lots of 10000 readings.
MMA7660FC – 6 bit acceleration value in 1 byte for each axis 650 RPS.
ADXL345 – 10 bit acceleration value in 2bytes for each axis 435 RPS
Netduino Plus using a SeeedStudio Grove Base Shield, MMA7660FC twig & ADXL345 twig.
The devices also have configurable acquisition rates & in some cases FIFOs for queuing readings which I need to look at some more
Two Analog devices ADXL345 Twigs from Seeedstudio arrived today. These offer much better sensitivity than the MMA7660FC Twigs that I have been using. The MMA7660 has a 6 bit 2’s complement output for X,Y & Z acceleration whereas the ADXL has 10 bit resolution in the +-2G range which I would be using.
I have also ordered a couple of MMA8451Q Accelerometer breakout boards from a vendor in China. These have a 14 bit accuracy and have a low noise mode which looks promising. The low noise mode requires a bit more power but for a non mobile application this shouldn’t be an issue.
WIll be ordering a Netduino Plus 2 as soon as availability confirmed
168MHz CPU (was 48MHz)
384 KB Code storage (was 64KB)
100+KB RAM (was 42KB)
Plus other improvements, I wonder what the impact of the faster CPU on power consumption will be as I have just purchased a solar panel & battery from seeedstudio.
The extra RAM should make the QuakeZure client software a lot easier as no more mucking around with shunting data off to the SD card to save space.
Including a GPS in the QuakeZure device significantly increases the cost (e.g. Grove GPS twig USD39.90) but should improve the robustness of the event identification (by comparing the arrival time at multiple sites) and improve the accuracy of the event timestamping for post processing.
Need to look at the comparative accuracy of GPS & NTP times.
After some quality google time I found this article published on the American Geophysical Union (AGU) from 2008 which discusses how such an Earthquake Early Warning (EEW) system could work, and other issues such as the performance limitations based on the size of the sensor array.
Now I think it’s time to install streaminsight and see what how good a proof of concept I can build to validate my backoffice approach.