Inspiration
About 46 large earthquakes happen every single year around the world, and tons of tiny earthquakes happen almost every single hour. Between 1998 and 2017, 750 thousand people have lost their lives to earthquakes, accounting as over 50% of the total lives taken by natural disasters. A total of 125 million people have impacted in the same timeframe with brutal injuries, the loss of housing, and sometimes the loss of family/friends. And, what makes this worse, is that earthquakes isolate that specific area from the rest of the world. This means that the people who survived must immediately start rescuing those who fell victim to this natural disaster. Diverging from human lives, Earthquakes also lead to the destruction of many buildings. A strong example of this is the 2023 earthquakes in Syria and Turkey, which led to a collapse of 84,000 buildings. This displaces millions of people and sets the countries back YEARS in economic and technological progress. In the area where I live, there are tons of Earthquakes that are happening every single second. For example, the place that I live in faces over 1500 micro-quakes every single year. Living so close to the San Andreas fault, it makes it very necessary to have proper protection against Earthquakes. And, what is most surprising, is that despite all of the damage that earthquakes do, they still remain to be a very overlooked aspect in the world.
Hence, I wanted to solve this problem by providing users with a all-in-one system that limits the effect that earthquakes have on society. It automatically calls 911 when it senses danger to account for the isolation that occurs and it deems whether building's are structurally safe after earthquakes to ensure that no further lives are lost. Another main reason for this is due to the fact that earthquakes are major in California. As I apply for this challenge, I see that an earthquake has literally happened today morning about 43 miles from Fortuna, CA. Locally, earthquakes are a major problem, and it would be really useful to solve the harm that these natural disasters do to our community.
I also realized that detecting an earthquake and judging a building's safety are fundamentally data problems, not just hardware problems. A sensor in a real home is constantly picking up noise: footsteps, slammed doors, passing trucks, and even the temperature changing throughout the day. A system that simply alarms whenever a number crosses a line would cry wolf constantly, and people would stop trusting it. On the other hand, a system that misses a real earthquake could cost lives. That is why I wanted Seismic to use statistical models and AI-driven reasoning that can separate real seismic events from everyday noise, and that can tell a user not just whether a building might be damaged, but how confident the system is in that answer.
What it does
My app is an Native iOS app that is an advanced earthquake detection and safety platform combining physical hardware, real-world data, 3D simulation, and AI. It helps users detect earthquakes, understand their effects on buildings, monitor earthquake activity, and make informed safety decisions.
The Arduino Mega is connected to an accelerometer, motion sensor, sound sensor, and stepper motor. The three sensors detect unusual shaking and movement and send information to the Arduino. When an earthquake is detected, the Arduino activates the stepper motor, which rotates to symbolize shutting off water and electricity. I chose these utilities because electrical systems can become especially dangerous when water is present, creating additional hazards during earthquakes.
Instead of trusting any single sensor, the detection system treats the decision like an ensemble classifier. Each sensor casts its own vote on whether an earthquake is happening, and an event is only confirmed when at least two of the three sensors agree. This two-out-of-three voting dramatically reduces false alarms, because one noisy reading, like a door slam picked up by the sound sensor, can never trigger the alarm on its own. On top of this, the accelerometer data is run through an STA/LTA (short-term average / long-term average) detector, which compares the energy of the most recent shaking to the normal background level, the same core approach used by professional seismic networks.
The 3D simulation demonstrates how a building could respond to earthquake forces. Building movement is exaggerated by 40 times so users can clearly see potential damage. Information such as building height, weight, and construction material is entered into a complex physics and mathematics calculator that determines how the structure should respond. The app calculates an estimated damage percentage and determines whether the building may be safe to re-enter. Additional calculations occur in the background, while a settings toggle allows users to view detailed numerical information.
The safety decision is not a simple yes or no. The app's evidence-based assessment engine combines several independent indicators of damage, such as how much the building's natural vibration period has shifted, how far the building has permanently moved, and how much it has tilted. It weights each one by how reliable it is, and produces a final verdict along with a confidence interval. This means a user sees something like "likely damaged, with a certain level of confidence," which is far more useful for a real safety decision than a single unexplained number.
The Map feature uses APIs including Tavily, Serper, OpenWeather, and Wikidata to gather real-world information. It combines this information into a large interactive map containing earthquake statistics and historical activity for different locations. The map can also identify buildings damaged by recent earthquakes and provide an estimated probability of future earthquake activity in an area.
The Home page summarizes information from other sections into clean, customizable widgets. Users can reorganize these widgets based on the information they want to see first.
The Network feature allows multiple hardware systems to communicate across a city, state, or potentially an entire country. When one system detects an earthquake, it can notify other connected households within the affected area. With many sensors reporting together, the app can also use network-inversion techniques to estimate where an earthquake started, based on when and how strongly each sensor felt the shaking.
The Feed provides a continuously updating tracker of earthquakes around the world, allowing users to monitor global seismic activity in real time.
The Library allows users to import real-world buildings into the simulator. APIs search for information about the building and provide statistics that can be entered into the physics simulation.
The Settings tab allows users to customize the app's background, haptics, and voice features. It also provides detailed explanations of the calculations, algorithms, and AI models used throughout the application. My goal was for the AI to never be a black box, so every model and assessment in the app comes with an explanation of how it reached its conclusion.
The app supports Apple Login, Google Login, and traditional username-and-password authentication.
How we built it
I have designed and coded Seismic iOS app in Swift, SwiftUI, and Swift Package as a cross-cutting platform that unifies seismic-hazard detection, structural health monitoring, geospatial analysis, embedded systems, and three-dimensional simulation in a single engineering platform. The application is organized as seven distinct software modules called SeismicCore, SeismicSignal, SeismicGeo, SeismicStructures, SeismicDevice, SeismicData, and SeismicServices. Each module implements particular functions ranging from mathematical and signal-processing algorithms to structures analysis, device communication, data storage, and third-party services messaging. The overall design is aimed to decouple the algorithmic code from the application logic so that any algorithm could be validated in isolation without launching the iOS simulator.
I have designed a seismic signal-processing pipeline that implements a set of industry-standard algorithms. These include waveform conditioning, event detection based on short-term average/long-term average thresholding, matched filtering, power spectral density estimation with Welch's method, spectral peak picking, Hilbert envelope analysis, damping estimation, and response spectrum calculation. The pipeline plots the spectrogram that visualizes the time-varying spectral content and illustrates the peaks' prominence to extract the most prominent modes. In addition, three different natural period estimation approaches are implemented to provide an opportunity to compare the results of various methods side by side. All calculations are visualized in plots that help the user understand the process's logic and see the data that influence the outcome.
From a machine learning perspective, this pipeline works as the feature-extraction stage of the system. Raw accelerometer data is far too noisy and high-dimensional to reason about directly, so the pipeline converts thousands of raw samples into a small set of meaningful features: dominant frequencies, peak prominence, damping ratios, and signal envelopes. Event detection itself is treated as a classification problem with a tunable decision threshold, which taught me to balance precision and recall: set the threshold too low and the system raises false alarms, set it too high and it misses real earthquakes. Matched filtering adds a template-matching approach, scoring how closely incoming signals resemble known seismic waveforms, similar to how a pattern-recognition model compares new inputs against learned examples. Running three independent natural-period estimators side by side also acts like a small ensemble, letting the methods cross-check one another instead of trusting a single estimate.
To support structural health monitoring, I have implemented a pipeline that estimates temporal trends of the structure's natural period, residual displacement, and tilt. To reduce the impact of temperature variations on the vibration frequency, a building-specific temperature-frequency regression is estimated for each building. To mitigate the effect of outliers, a robust regression with outlier detection is applied to the same data sets. To combine the trends and provide an overall assessment of structural performance, I have designed an evidence-based reasoning engine that utilizes multiple evidence sources and applies different weights and textual annotations to the outcomes of each process step. This engine generates a structural assessment and produces a confidence interval as an estimate of certainty about the structural performance. Furthermore, I have implemented a Coordinate Modal Assurance Criterion analysis that compares the structural characteristics in two different states and designed a structural response-analysis engine that evaluates the structure's seismic response.
The temperature-frequency regression solves a classic confounding-variable problem in machine learning. A building's natural frequency naturally drifts as materials expand and stiffen with temperature, so a drop in frequency on a hot afternoon does not necessarily mean damage. The model learns each building's own temperature relationship, and then the system judges damage from the residual, the part of the frequency change that temperature cannot explain. Because ordinary least-squares regression can be pulled far off course by a single bad reading, the robust regression down-weights outliers so that one glitchy sensor value cannot corrupt the whole model. The evidence-based reasoning engine is built on the same idea as Bayesian inference: each independent line of evidence updates the overall belief about the building's condition by an amount proportional to how reliable that evidence is, and the final result is reported with a confidence interval rather than as a false certainty. The COMAC analysis acts as a similarity metric between the building's "before" and "after" vibration patterns, pinpointing where the structure's behavior has changed the most.
I have designed and coded an interactive three-dimensional building simulator that utilizes the building description and historic seismic trace to visualize the impact of ground shaking on the structure. The application allows the user to select a building of interest and explore the building's description, analyze the seismic response, and compare the simulation traces. The simulator includes a visualization of the vibration modes, response spectra with a building-specific natural period, comparison of building frequencies, animated spectrogram, and audio version of the seismic trace with natural periods shifted up by six octaves to hear the fundamental tones.
I have built an Arduino MEGA 2560 sensor node that communicates with the iOS application over Bluetooth Low Energy using a custom protocol. The sensor node is designed to monitor ground shaking, tilt, sound, temperature, and occupancy with multiple sensors. The node implements a multi-sensor fusion algorithm that uses a two-out-of-three voting scheme, provides real-time telemetry, countdown visualization, audible alerts, transistor-controlled power relays, and a stepper motor driver for a water-main shut-off valve. The node records audio and motion data with MPU6050, senses tilt, sound, temperature, and occupancy, and transmits this information to the iOS app over Bluetooth serial lines using a custom protocol. The communication protocol uses newline-delimited JSON, and messages are protected by a checksum. Furthermore, the node utilizes a chunked recording approach with selective chunk retransmission upon request. The power-down state is monitored with a photoresistor to ensure that the power indicator switch is activated.
The multi-sensor fusion algorithm is a form of ensemble decision-making running directly on the microcontroller. Each sensor acts as an independent "weak classifier" with its own blind spots: the accelerometer can be fooled by someone bumping the table, and the sound sensor can be fooled by loud noises. By requiring agreement between at least two of them, the system's combined decision is much more reliable than any single sensor. Running this logic on the Arduino itself, at the edge, means the node can make a safety decision in milliseconds, even if the phone is disconnected.
I have designed the geospatial module for earthquake mapping, network analysis, geometry operations, and source localization. The application utilizes USGS earthquake data, including aftershock forecasts, OpenStreetMap mapping data, and building data from Wikidata services. The network-inversion tools are implemented to localize earthquakes based on sensor data and illustrate the relative location of the earthquake and the sensor network. In addition, the application stores historical earthquake information, building data, and synthetic sensor data to provide an overview of the system's capabilities when launched for the first time.
Source localization is an inverse problem: instead of predicting what sensors will feel from a known earthquake, the system works backward from what the sensors actually felt to estimate where the earthquake most likely started, finding the location that best explains all of the observations at once. The synthetic sensor data plays an important role here as well. Because I know exactly what earthquake produced each synthetic signal, it acts as labeled ground-truth data that I used to check whether my detection and localization algorithms return the correct answer.
I have designed the system with persistent data storage, tamper-evident measurement logging, configurable API tokens for third-party services, an optional AI-powered analysis module, and a deterministic on-device narration system. The user interface is unified around a Live Activity and Dynamic Island countdown, real-time sensor visualization, community earthquake map, structural-health assessment panel, and automated walkthrough upon launch. I have written nine hundred and sixty-six tests across seven software modules to validate the correct operation of algorithms, interfaces, numeric calculations, communication protocols, data storage, and network-client behavior. The tests help ensure the reliability of each individual algorithm while building confidence in the overall design that ties together scientific computing, embedded systems, and structural-engineering algorithms.
The optional AI-powered analysis module takes the results of the signal-processing and structural-assessment engines and turns them into a plain-language explanation that a regular person can act on. I deliberately paired it with the deterministic on-device narration system, so that the core safety information never depends on an internet connection or a third-party AI service. If the AI service is unavailable, the app still delivers its assessment using its own built-in logic. This design taught me an important principle of applied AI: the most critical decisions should always have a reliable, explainable fallback.
Also, as a side note, we did use Claude for debugging and writing the code when the calculations involved complex differential equations and matrix calculations. Apart from that, overall most of the work was mine!
Challenges we ran into
Overall, this project lasted me a TON of continuous building, dedication, and tinkering to land upon a final result. Over this timeline, I faced MANY problems, and I will list the major ones here:
BLE Connection with Phone: I used a Bluetooth Low Energy to connect my hardware with my phone. One of the main errors was the data that was sent was bugged with errors. I spent countless hours re-working out the hardware because I believed that the issue was with the data being sent. However, the main problem was that the BLE kept cutting out some of the data because the numbers were too big to send. Hence, I had to use a system that would constantly rotate between sending data at rapid speeds. While this increased the tempo of the data being sent it prevented from data corruption and ensured stability. This was especially important for the analysis side of the app, because every algorithm downstream, from the STA/LTA detector to the structural assessment engine, is only as good as the data it receives. Corrupted or missing samples would have quietly distorted the frequency analysis and could have produced false damage assessments.
Lag on Phone: This problem was created due to the solution of the previous problem. As the cycle occurred with fast reiterations, the constant data in my phone made the app lag. I once remember keeping the app open for 30 seconds and watching my phone crash as it was overwhelmed with the data that the Arduino sent. To fix this, I created a "middle" stage in the process of the data transfer. I figured much of the lag was happening with the rendering of the graph and the translation of the numbers if human-readable text. Hence, I made a "storage" space of the screen when the iPhone would store the raw numbers of the data. It would then slowly take data from that storage and compress it into chunks, which would then be translated into the graph and the sentences/statistics of information. This buffer works much like a data pipeline in a machine learning system: raw data is collected first, then processed in batches, so the heavy analysis never blocks the real-time collection of new measurements.
Simulation Spacial Rendering: For the early stages of the simulation feature in my app, I continuously tested and compared the simulations with those in another project that I have made. I constantly noticed errors in the motion and the output data. What happened was an error in the rendering of the data, and hence the simulation was skewed. To fix this, I made a separate hidden simulation that used spacial linear averages and regression lines to calculate the average structural points of the building. After finding those important points, I incorporated their 3D coordinates and the vectors of the force, and then used differential equations to ensure that the simulation was rendered accurately. Using regression to find these representative points meant the simulation was driven by a fitted model of the building's structure rather than by every individual rendered point, which made the motion far more stable and physically consistent.
Accomplishments that we're proud of
One of my proudest achievements was evolving Seismic from an initial concept into a cohesive engineering platform that weaves together iOS-native development, embedded electronics, structural engineering, scientific computing, geospatial analysis, and artificial intelligence. Instead of an application that simply alerts the user to an earthquake, I designed an interconnected suite in which sensors detect seismic activity, algorithms analyze measurements, a 3D simulator acts as a test bed, and an evidence-based assessment engine compiles findings about likely building damage. My proudest achievement was bringing together these disparate fields of engineering into a unified application.
Another achievement of which I am particularly proud was designing the application's scientific computing engine. Within Seismic, I implemented 74 algorithms for signal processing, structural engineering, statistical analysis, geospatial computing, and mathematical modeling. These include STA/LTA-based earthquake detection, matched filtering, Welch power spectral density, spectral peak picking, Hilbert-envelope analysis, damping estimation, response-spectrum calculation, and COMAC analysis. In addition, I implemented three independent algorithms to estimate a building's natural vibration period. Rather than presenting the user with an unexplained number, I provided interactive visualizations that exposed the underlying waveforms, spectra, peaks, and calculations. Together, these algorithms form a complete data pipeline, from raw sensor signals, to extracted features, to statistical models, to a final decision with a measure of confidence, which is the same structure used in professional machine learning systems.
I am also incredibly proud of the contribution that I made to Seismic's structural health monitoring system. Rather than use a naive approach that relied on a single metric, I designed an algorithm that used diverse lines of evidence to evaluate buildings. First, I implemented a temperature-frequency regression model that accounted for temperature-induced shifts in resonance frequencies. Second, I applied statistical techniques to remove outliers. Third, I designed an evidence-based assessment algorithm that weighted natural-period shifts, residual displacement, and tilt meters. With this approach, I provided interactive explanations for every metric while estimating the likelihood of damage with a confidence interval. In doing so, I had to reconcile mathematical precision with real-world engineering intuition. What I am most proud of here is that the system knows what it doesn't know. By quantifying its own uncertainty, and by separating true structural changes from environmental effects like temperature, the assessment engine avoids the most dangerous failure of an AI system: being confidently wrong.
Another accomplishment that I made was designing the application's interactive 3D simulator. Within the application, I designed a system that allowed the user to load building models, query building information, select past earthquakes, and view the resulting response. In addition, I implemented visualizations of vibration modes, response spectra, animated spectrograms, and comparisons of natural frequencies. In addition, I synthesized an audio representation of the building's vibrations by virtue of shifting its natural frequencies up six octaves while preserving amplitude ratios. Finally, I tied together these disparate elements into a simulator that allowed the user to interact with the building model and grasp the connections between building response and earthquake physics.
I am also proud of the contribution that I made to the software-hardware integration that powers Seismic. In particular, I designed the sensor fusion logic that feeds into the application's analysis engine. Specifically, I fused together the data from an accelerometer, tilt switch, sound sensor, thermistor, photoresistor, and occupancy sensor in a custom sensor array. A microcontroller within an Arduino MEGA 2560 acted upon this information and communicated with the smartphone over Bluetooth Low Energy. In particular, I implemented a custom newline-delimited JSON-based protocol that allowed the smartphone to process sensor data, receive seismic recordings, send countdown information, provide alarms, manage power switching with transistors, and control stepper motors that emulate utility switches. Perhaps my most creative contribution to the system, however, was implementing photoresistor feedback to the smartphone in order to verify that the on/off state of the power indicator has changed. The sensor fusion approach also brings intelligence to the edge: the Arduino itself makes the first-pass detection decision through ensemble voting, so the most time-critical safety actions happen instantly on the device, while the phone handles the deeper statistical analysis.
In addition to the application itself, I am also incredibly proud of the seven software modules that comprise it. These independent modules manage the core mathematics, signal processing, geospatial analysis, structural health monitoring, device communication, persistence, and services that power the application. In addition to developing original algorithms, I also integrated USGS earthquake feeds and aftershock forecasts, OpenStreetMap maps and building information, historical earthquake data, and local demonstrations. Finally, I designed the application to demonstrate its core capabilities without API keys or external service access by virtue of local data and demonstration data sets that populated the simulator at launch.
Finally, I am proud of the work that I did to implement the application's automated testing framework. The application's test suite contains 966 assertions across all seven modules. In addition to testing core algorithms, I also performed unit tests and visual assertions across the app's mathematical, signal-processing, geospatial, structural health monitoring, data persistence, and device communication modules. Furthermore, I implemented automated demonstrations that tied together the building simulator, earthquake sequences, hardware telemetry, building response, and geospatial analysis. All in all, my contributions to Seismic went well beyond simply designing an application. By virtue of my work, I built an end-to-end engineering platform that touches upon diverse fields of mathematics, electronics, software development, and real-world earthquake preparedness. Validating each algorithm against synthetic data with known correct answers gave me the same kind of ground-truth testing that machine learning engineers rely on, so I could prove that every model was producing the right results before trusting it with real-world data.
What we learned
There were many things that I took away. Many of the items that I took away were technical, but some were also non technical.
Technical: On this journey to making this project, I learned a lot about coding. When I say a lot, I mean a LOT. Although this seems pretty-obvious, I learned the many wonders of coding native iOS apps, initializing a Google Sign-in, setting the live data from the app into servers from Supabase, and using the various API's and learning about their functions. Also, I learned how to do much more complex projects with the Arduino including using capacitors, resistor chains, and displays to show information. Last but not least, another major technical item that I learned was how to establish connections between the hardware and the software using a BLE.
The biggest technical lesson, though, was learning how to turn noisy real-world sensor data into decisions people can trust, which is where machine learning and statistical inference came in. I learned that event detection is really a classification problem, and that every threshold is a trade-off between precision and recall, between false alarms and missed earthquakes. I learned how ensemble methods, like my two-out-of-three sensor voting, make a combined decision far more reliable than any single noisy input. I learned that models must account for confounding variables, which is why my temperature-frequency regression judges damage from the residual rather than from the raw frequency change, and why robust regression is needed so a single bad reading cannot corrupt the whole model. I also learned the core idea behind Bayesian reasoning: each new piece of evidence should update a belief in proportion to how trustworthy it is, and an honest system should report how confident it is, not just what it thinks. Finally, I learned that the most valuable AI is explainable AI. A prediction that users cannot understand is a prediction they cannot trust, which is why every model in Seismic shows the data and reasoning behind its conclusion.
Non-Technical: I always thought that making an app was something simple. Something that could be done in hours. However, making this application took days for me and it goes to show the true dedication that all the engineers around the world take. The true dedication that it takes to make all of these projects. Each application on app store was made by countless developers, each website on the internet was made by countless developers, and an OS or a computer itself was made by countless of developers. Making hardware and software applications truly takes a next-level of dedication from the human race. Additionally, I learned more about the statistics and physics of earthquakes. I spent a lot of time simply researching information about the effects of earthquakes and the causes of earthquakes. To make this app, I had to use many of my learnings about earthquakes like the rhythmic frequencies, the structural integrity of buildings and many other calculations.
Overall, while making this project gave me many teachings about the technical side, it also gave me a lot of learning on the other side. In addition to learning more about coding and hardware, I also learned more about earthquakes and the effort that it takes into making applications. This truly was a beautiful learning experience for me and I would definitely do it again.
What's next for Seismic
Overall, though this application was complex, I still believe there is tons of room for improvement!
Worldwide Accessibility: Currently, all the words and sentences of my application are in English. This is mainly because the API is only accurate in English and the built-in algorithms are only meant to work in English. If this application was meant to work for the entire world, I would need to ensure that there are multiple language features in the application. I would also hope to include many native dialects for the languages so that this application is open to everyone around the world.
Hardware/Arduino Appearance: Currently at this point in time, the Arduino side of the project looks like a jumble of wires. It appears very hard to differentiate the connections and identify errors in the problem. If I had access to a 3D printer, I would CAD (computer-aided design) a container that could organize the position of the sensors, sort and position the wires to ensure easy connection readability, and protect the device from any external forces. If I ever want to monetize the hardware, I would have to ensure that it comes in a proper package and ensures a 100% success rate of wire connections and other sensor functions. Also, currently the Arduino remains connected to my MacBook. To ensure the Arduino's easy mobility, it must be connected with a battery that is preferably rechargeable. Also the Arduino must send signals to the phone to recharge the battery whenever it feels that the power is low.
Hardware/Software Connection: As of right now, the connection between my Arduino and my iPhone is pretty weak. I would have to figure out a way to ensure that the connection between the 2 can remain strong throughout the whole house, and even maybe the neighborhood. Sometimes after shutting off my iPhone, the connection with the hardware disappears. This simply cannot happen as that would mean that closing your phone completely destroys the Arduino's purpose. I would have to use devices apart from Bluetooth to ensure a long range and stable connection.
UI/App Fixes: Currently the functionality of the app is perfect in my opinion and I cannot find any flaws. However, other people might have other preferences and would sometimes consider the UI as overwhelming. Hence, I believe I must clean up the UI a bit to ensure higher readability for the user.
Learned Detection Models: Right now, the detection system relies on carefully tuned thresholds and voting rules. As more Seismic nodes are deployed and record real events, I would like to use that growing dataset to train a machine learning classifier, for example an on-device Core ML model, that learns to tell earthquakes apart from everyday vibrations like footsteps and traffic far more accurately than fixed thresholds can. Each household's node could also learn its own "normal" background vibration, so that detection automatically adapts to every home.
Smarter Damage Prediction: The evidence-based assessment engine currently uses weights that I designed by hand. In the future, I would like to calibrate those weights using real structural data, such as buildings that were inspected after past earthquakes, so that the confidence intervals are learned from real outcomes instead of set by me. Combining the network's many sensors could also let the system compare buildings across a whole neighborhood, flagging the ones whose behavior changed the most after an earthquake so inspectors know where to look first.
Built With
- c++
- javascript
- json
- openweather
- serper
- swift
- tavily
- vscode
- wikidata
- xcode
