This article explores the suitability of a Wii nunchuk based USB accelerometer as an earthquake sensor for the Quake-Catcher Network (QCN) project. It examines the nunchuk over several metrics: precision and range, frequency response, total cost and availability.
The Quake-Catcher Network is a collaborative initiative for developing the world’s largest, low-cost strong-motion seismic network by utilizing sensors in and attached to internet-connected computers. With your help, the Quake-Catcher Network can provide better understanding of earthquakes, give early warning to schools, emergency response systems, and others. The Quake-Catcher Network also provides educational software designed to help teach about earthquakes and earthquake hazards.
Range and Precision
QCN supports a few different USB accelerometers. The most basic one is the JoyWarrior24F8 (JW24F8), which is a 3 axis accelerometer with 10 bits of precision and a measurement range of +-2g, +-4g, or +-8g. QCN uses the +-2g range. According to WiiBrew, the Wii nunchuk’s accelerometer also has 10 bits of precision over a range of +-2g. Therefore, the nunchuk meets the first criteria for evaluating its suitability as a QCN sensor.
Data Comparison
I don’t have access to a shake table so I’m unable to directly evaluate the frequency response of the nunchuk based USB accelerometer. However, QCN did provide me with a JoyWarrior24F8 USB accelerometer for comparison. Since the frequency response of the JoyWarrior24F8 was already deemed suitable by Prof. Cochran for QCN, I simply had to attach the JoyWarrior24F8 and the nunchuk to the same substrate, shake them by hand at various frequencies while recording data from both sensors simultaneously, and compare the Fourier transform of the nunchuk’s data to the transform of the JW24F8’s data.
Here are comparisons of an official (i.e. STMicroelectronics accelerometer) nunchuk to the JW24F8. The microcontroller code used was mega32u4_hard-i2c_no_filter.zip and the plots were made using the Octave scripts found in the code section below.
Accelerometer X-axis data comparison
Time domain plots:
Frequency domain plots:
Accelerometer Y-axis data comparison
Time domain plots:
Frequency domain plots:
Accelerometer Z-axis data comparison
Time domain plots:
Frequency domain plots
The STMicroelectronics based nunchuk appears to have a response that is very similar to the JW24F8’s response. It should be noted that I was shaking the accelerometers by hand so I don’t think I covered the entire range of frequencies of interest.
Fakes
Unfortunately, there are fake (i.e. 6331 accelerometers) nunchuks that are unsuitable earthquake sensors because their accelerometer data has stuck bits. Even worse, it can be very difficult to impossible to tell if a nunchuk is official by external examination only.
Microcontrollers
The nunchuk uses I2C to transfer its data. Therefore, a microcontroller that supports USB and I2C is required to read the data from the nunchuk, filter it, and pass it to the host computer. Three different microcontrollers were evaluated: an ATmega32U2 board that supports hard USB and soft I2C, an ATmega328P with V-USB that supports soft USB and hard I2C, and an ATmega32U4 (teensy) that supports hard USB and hard I2C. The ATmega32U2 only works with 6331 based nunchuks and only at 100 kHz. The ATmega328P works with both STMicroelectronics and 6331 based nunchuks, but the two-wire interface (TWI) eventually locks up for an unknown reason. The ATmega32U4 works with both types of nunchuks tested and with no crashes observed over a two-week period. The STMicroelectronics nunchuk works at 100 and 200 kHz with hard I2C only. The 6331 based nunchuk works at 100, 200, and 400 kHz when hard I2C is used.
Cost
A Quake Catcher Kit from Saelig is $42.25 with about $12 for shipping to a U.S. residence, for a total of $54.25.
A Teensy with a 3.3V regulator and shipping costs about $22. A genuine, official nunchuk is approximately $20 shipped. A nunchuk extension cable from eBay is around $4.50. For a total price of $46.50. However, the cost of a proper mount for the nunchuk as well as the labor cost of assembly has not been included. Therefore, I believe that Quake Catcher Kit is most likely a better deal for your time and money.
Code
All of the code in one GitHub repo.
_Microcontroller code_
The output resulting from microcontroller code that didn’t filter the accelerometer data was the most similar to the output of the JW24F8. Code that filters the accelerometer data with Chebyshev and moving-average filters is included for comparison purposes and because I’d already written it.
This code is for research purposes only; it uses an Atmel USB VID/PID pair for LUFA demos only. This code doesn’t work with QCN because the QCN software checks the joystick’s name to make sure it’s a JoyWarrior. This code can be easily made to work with QCN by modifying its USB descriptors, which I’ve done, but I won’t be releasing this code since it uses Code Mercenaries’s VID/PID. The code also checks the connected controller’s identification bytes to make sure its a genuine Wii nunchuk. It doesn’t work with fake nunchuks.
Wii Nunchuk quake sensor code for teensy (no filter)
Wii Nunchuk quake sensor code for teensy (moving average)
Wii Nunchuk quake sensor code for teensy (chebyshev)
_Host code_
Joystick Accelerometer Data Acquisition code for Linux
Jonathan Thomson's web journal 
Jonathan
Thanks for this article.
Are the bottom links correctly formatted? The Octave link is the only one that works for me; the others fail with page not found.
Neil
The links are fixed now. Thanks for catching that. I don’t know how I missed it.
Do you know the output format of QCN sensor?
The JW24F8 outputs the three accelerometer axes as three unsigned 16 bit ints and eight buttons all stored in an unsigned 8 bit int.
nunchuk_quake_sensor.h
typedef struct
{
uint16_t ax; /**< accelerometer x axis */
uint16_t ay; /**< accelerometer y axis */
uint16_t az; /**< accelerometer z axis */
uint8_t buttons; /**< Bit mask of the currently pressed joystick buttons */
} USB_JoystickReport_Data_t; \
Descriptors.c
const USB_Descriptor_HIDReport_Datatype_t PROGMEM JoystickReport[] =
{
HID_RI_USAGE_PAGE(8, 0x01), /* Generic Desktop */
HID_RI_USAGE(8, 0x04), /* Joystick */
HID_RI_COLLECTION(8, 0x01), /* Application */
HID_RI_USAGE(8, 0x01), /* Pointer */
HID_RI_COLLECTION(8, 0x00), /* Physical */
HID_RI_USAGE(8, 0x30), /* Usage Direction-X */
HID_RI_USAGE(8, 0x31), /* Usage Direction-Y */
HID_RI_USAGE(8, 0x32), /* Usage Direction-Z */
HID_RI_LOGICAL_MINIMUM(8, 0), /* LOGICAL_MINIMUM (0) */
HID_RI_LOGICAL_MAXIMUM(16, 0x03ff), /* LOGICAL_MAXIMUM (1023) */
HID_RI_PHYSICAL_MINIMUM(8, 0x00), /* PHYSICAL_MINIMUM (0) */
HID_RI_PHYSICAL_MAXIMUM(16, 0x03ff), /* PHYSICAL_MAXIMUM (1023) */
HID_RI_REPORT_SIZE(8, 0x10), /* REPORT_SIZE (16) */
HID_RI_REPORT_COUNT(8, 0x03), /* REPORT_COUNT (3) */
HID_RI_INPUT(8, HID_IOF_DATA | HID_IOF_VARIABLE | HID_IOF_ABSOLUTE),
HID_RI_END_COLLECTION(0),
HID_RI_USAGE_PAGE(8, 0x09), /* Button */
HID_RI_USAGE_MINIMUM(8, 0x01), /* USAGE_MINIMUM (Button 1) */
HID_RI_USAGE_MAXIMUM(8, 0x08), /* USAGE_MAXIMUM (null) */
HID_RI_LOGICAL_MINIMUM(8, 0x00), /* LOGICAL_MINIMUM (0) */
HID_RI_LOGICAL_MAXIMUM(8, 0x01), /* LOGICAL_MAXIMUM (1) */
HID_RI_REPORT_COUNT(8, 0x08), /* REPORT_COUNT (8) */
HID_RI_REPORT_SIZE(8, 0x01), /* REPORT_SIZE (1) */
HID_RI_INPUT(8, HID_IOF_DATA | HID_IOF_VARIABLE | HID_IOF_ABSOLUTE),
HID_RI_END_COLLECTION(0),
};
Thnaks
Nevertheless the output data of O-Navi sensor is 16bits as you indicate. But I don’t see the “HID_RI_LOGICAL_MAXIMUM(16, 0x03ff), /* LOGICAL_MAXIMUM (1023) */ corresponding to 10bits.
I’ve never played with the O-Navi sensor and I didn’t mention it in the article. The nunchuk and the JW24F8 only have 10 bits for each accelerometer axis. 10 bits –> 2^10 = 1024 –> 0 through 1023
Exact, sorry.
Thanks you for your answer.
[…] Using a Wii Nunchuk as an seism sensor Here is an unobstructed seed shock sensor based on the Wii Nunchuk. A Teensy is secondhand to read the I2C accelerometer yield: associate […]
Does the accelerometer have damping. After a sharp impulse, what happens, does it stop within a cycle or 2 or does it ring. An accelerometer for seismic purposes should have a damped response.
After thinking about this, I realized that the resonant frequency of the MEMS resonanting beam is much much higher than the frequency of interest. So it doesn’t matter if there is no damping and the beam’s amplitude damps on it’s own naturally. What is a typical resonant frequency of a MEMS sensor.
So, from your idea, It is possible to build standalone detector based on one nunchuk, arduino (code for nunchuk already available) and Ethernet or GSM shield board to transmit without PC an alert when there is an Earthquake. This for “low cost system”.
I made a quick test with Arduino and Nunchuck and it works fine!
So what about using TI’s Stellaris Launchpad for the microcontroller. $5 (currently, and final price will be less than $10). Has hardware USB, hardware I2C.
(Sure the 80MHz ARM cpu is a lot more compute power than you need, but less expensive than options mentioned here.)
Or could try using this with a Raspberry Pi – i2c interface and skip USB all together.
I found this in web http://www.jouin.eu/phpBB/movies/detecteur_sismique_autonome_(prototype).flv
[…] Image from “Using a Wii Nunchuk as an earthquake sensor” – [Link] https://jethomson.wordpress.com/2012/05/16/using-a-wii-nunchuk-as-an-earthquake-sensor/ […]