Low-Cost Earthquake Shaking Alarm and Intensity Network for Schools

The problem: no warning during the shaking, no data after it

Northern Pakistan, Kashmir and the wider Himalayan belt sit on one of the most active collision zones on Earth. Earthquakes there have caused terrible loss of life, and school buildings have repeatedly been among the worst affected. Two moments matter most. In the first seconds, children who drop, cover and hold, or move away from windows, are safer. In the first hours, engineers and rescuers need to know which buildings shook hardest, so they inspect those first.

Earthquakes send a faster, weaker wave (the P wave) ahead of the slower, destructive waves. A sensor in the building can detect the first wave and sound an alarm, giving a few seconds of warning depending on distance from the epicentre. The same sensor records how strongly the building shook, which is exactly the information needed for damage triage.

What already exists and the gap

• National seismic networks locate earthquakes and issue reports, using high-quality instruments at relatively few sites.
• Google's Android Earthquake Alerts System uses accelerometers in Android phones to detect earthquakes and warn users in many countries.
• Raspberry Shake sells personal seismographs used by citizen scientists and schools for education.
• Commercial on-site warning devices exist for industrial facilities, usually at professional prices.

The gap is a low-cost, open design specifically for schools, combining an on-site alarm, a structural mounting guide and a building-level intensity map for inspectors, built and tested with clear limits.

Inspiration

Kong, Allen, Schreier and Kwon's paper "MyShake: A smartphone seismic network for earthquake early warning and beyond" (Science Advances, 2016) showed that cheap accelerometers in phones could tell earthquakes apart from everyday movement and contribute to early warning when combined across many devices. Your nodes are fixed to buildings, which removes much of the human motion noise MyShake had to deal with, but introduces new noise: doors, footsteps, generators and traffic.

What you build

• The node is bolted to a structural wall or floor, samples acceleration continuously and keeps accurate time.
• On-device detection watches for a sudden rise in shaking energy and checks its frequency content, then sounds the local alarm.
• After an event, the node reports peak acceleration and an estimated intensity to the server.
• Engineers and education officials see a map of schools coloured by measured shaking, to prioritise inspections.

The technically interesting part

• Detecting earthquakes, not footsteps. Use a short-term average to long-term average ratio trigger, the classic seismology method, and add checks on frequency and duration. Measure false triggers from slammed doors, children running and passing trucks during weeks of real recording.
• Speed versus certainty. An alarm that waits too long is useless; one that fires too easily is ignored. Explore the trade-off using replayed real earthquake records.
• Sensor quality. Cheap accelerometers are noisy. Compare a low-noise MEMS sensor with a common hobby sensor on the same shake table and quantify the difference.
• Timing. Comparing nodes across schools requires accurate time. Use network time with a hardware clock and measure drift.
• Intensity estimates. Convert peak acceleration to an intensity scale using published relationships, and state the uncertainty clearly.

How to evaluate it

• Detection: using replayed real earthquake recordings on a shake table or in software, measure detection rate and time to alarm.
• False alarms: triggers per week across real buildings during normal school days.
• Accuracy: recorded acceleration against a reference sensor on the shake table.
• Latency: time from event to intensity report on the server.

Suggested plan

• Weeks 1 to 3: basics of seismology and early warning, sensor choice, simple shake table.
• Weeks 4 to 7: firmware, sampling, timing, detection trigger.
• Weeks 8 to 10: alarm, reporting, server and map.
• Weeks 11 to 14: replay tests, building installations, false alarm monitoring.
• Weeks 15 to 16: analysis, report and demo. A second semester could add multi-node confirmation and building health tracking.

Path to a product

School networks, education departments, hospitals and disaster management authorities in earthquake-prone regions all need affordable monitoring. An open hardware design with a hosted intensity map, deployed with a disaster risk reduction partner, is a realistic route. The project builds sensing, real-time embedded and signal processing skills that apply across IoT, infrastructure and safety systems.

Scope warning

This is a research prototype; never present it as an official warning system or replace official alerts. Be honest that warning time near the epicentre may be zero. Work with school management on drills and get structural advice on mounting. Do not attempt to locate earthquakes or estimate magnitude; that is the job of national networks.

Learn what you need on Sefism

• Embedded systems and IoT roadmap: sensors, real-time firmware and connectivity.
• Embedded systems and IoT cheat sheet: sampling, timers and interrupts.
• FreeRTOS Documentation: structuring sampling and detection as tasks.
• Introduction to RTOS (video series): timing and priorities in practice.
• MQTT Essentials: fast, reliable event reporting.

Get help with this idea

False alarms and honest limits decide whether schools trust this. Tauseef can help you plan the shake table tests, the field recordings and the safety framing with a school partner. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session