The Problem
Hypothesis
It has been observed that major seismic events may be preceded by anomalies in natural radio signals, notably those <20kHz, i.e. in the audio frequency range (ELF/VLF). However, to date, no useful prediction system has been devised. This is hardly surprising, particularly because both the radio and seismic signals are extremely noisy in terms of information that might have local significance. It seems likely that the pattern matching sophistication required is beyond traditional signal analysis techniques (the observation of possible earthquake precursors has been done by humans). But recent developments in Deep Learning offer another avenue. It is supposed here that deep networks may be able to find the needle in the haystack.
Requirements
For an end-to-end system, the following are required:
- VLF receiver(s)
- Seismic sensor(s)
- Deep Network
- Notification system
There are extra requirements. To get a useful signal, VLF aerials need to be located away from sources of noise from the mains power supply. Similarly, seismic sensors need to be away from extraneous sources, ideally being physically attached to bedrock.
It is believed that the most straightforward way of attaching remote sensors to the ultimate processing system is to build independent subunits. So more complete requirements list is as follows, with components 1-4 as relatively self-contained subsystems:
- VLF receiver(s)
- Seismic sensor(s)
- Signal conditioning for the above
- Analog-digital conversion for the above
- Data transmission
- Preprocessing software
- Deep Network
- Notification system
Proposed Implementation
I really need to update these pages – see also Candidate Neural Network Architecture : PredNet
Development Process
Generally speaking, I’m starting with minimal experimental subsystems and iteratively improving (or rejecting) them.
This is an ambitious project and I’m working alone with very limited resources, notably at this point in time I’m lacking hardware components to do very much on that side – see Support this Project. Having said that, the system as a whole is very modular and when I can’t work on one part, there’s another on which I can.
Hardware
The planned hardware subsystems for 1-5 in the list above look like this:
There is more detail of this setup at Hardware Issues and some of the problems I’ve encountered so far at Hardware Delusions.
Software
The details of the software on the remote sensor subsystems will be dependent on the hardware chosen (Microcontroller in the diagram above). But from there to the processing host it is planned to used various standard protocols and frameworks.
So here we have:
- Data transmission
- Preprocessing software
- Deep Network
- Notification system
Data Transmission
Sharing of data captured by the sensor subsystems is very desirable, and to this end the plan is to follow, wherever appropriate, the Best Practices as documented around the W3C Web of Things (a good approach the Internet of Things, IoT).
The plan is to base the communication of data between remote subsystems and the processing subsystem using Linked Data Notifications. This seems a very good standards-based stepping stone to getting the data on the Web (via a proxy server).
Preprocessing Software/Deep Network
I’m currently investigating this part of the system, a working overview looks like this (the spectrogram sequence comes from the VLF subsystem):
The approach I’m considering is to log VLF as spectrograms and the seismic data as a time series of events.
The framework I have chosen for the Deep Learning network is Keras (on TensorFlow).
For more detail see Provisional Graph.
Notification System
A web-based pub-sub setup seems most appropriate, and Twitter fits the bill nicely (I’m @danja btw). It’s relatively straightforward to code against. For now I’m thinking in terms of predictions (datetime/magnitude/likelihood) and progress reports (accuracy – % missed events/false positives).
Don’t forget to check Support this Project!
ELFquake 