• Home
  • The Train Track
  • Sailing
  • The Food Lab
  • The Doggo
  • FILM
  • More
    • Home
    • The Train Track
    • Sailing
    • The Food Lab
    • The Doggo
    • FILM
  • Home
  • The Train Track
  • Sailing
  • The Food Lab
  • The Doggo
  • FILM

Analyzing Seismic Signals to Detect Trains (discontinued)

What if we can forcast train arrivals? Well, why would anyone want to do that...?

First Wireless Data Stream Test via LAN

UPDATE: this project and webpage are no longer WIP/maintained (or at least its initial object), but I keep it around to reminiscence. 

The Raspberry Shake

THE PLAN & WORKFLOW - A MOONSHOT

In order to accomplish this project's objective, I'll develop and incorporate the following tools:


1] IoT (via AWS) (not being used currently...)

2] pgAdmin4

3] Apache NiFi (not being used currently...)

4] macOS

5] Raspberry Shake 1-D

6] Python (obspy & boto3)

7] ZeroTier

8] BalenaCloud (not being used currently...)

9] Grafana

10] DynamoDB (via AWS) (not being used currently...)

11] AWS S3

12] AWS RDS

13] InfluxDB (being tested as a better option compared to TimescaleDB...)

14] Twitter


It's important to note that the so-called "moonshot" objective is far away from achieving. RIght now, my concern is with developing and testing the sensor streaming time-series data to cloud DB and then piping

that info to a publically available dashboard for viewing. Once that is done, I can start testing real-time analytics of seismic waveforms and creating alarms/notifications if train waveforms are detected. After this, preliminary field tests will be conducted after rugidizing the sensor for autonomous development and environmental conditions. This is indeed a rough draft but it's a manageable plan.

Curious?

The videos above show a system that is collective referred to as a "Raspberry Shake." There's a variety of such devices - if you're curious to learn more them, click the link below.  

learn more here

Latest news...

***[01/15/2020] >>> ]It's odd it use a geophone for this particular kind of application. I'd imagine that some kind of laser or optical system would perform much better. Regardless, I'd like to develop and apply what I know to address the problem listed above. Now, if the device/sensor is sensitive enough - which has yet to reliably determined - then perhaps it can outperform things like cameras or lasers in terms of better forecasting train arrivals from greater distances.


***[02/01/2020] >>> As a benchmark for this project, time-series seismic data will be sent to a PostgreSQL DB in AWS RDS (via Python's psycopg2 module). From there,  those data will be read real-time and visualized via a Grafana dashboard. Data are currently loading into the DB, but I have yet to connect Grafana to the table. Note that once this benchmark has been achieved, I'll start actively developing and incorporating more a best-practice approach. 


***[02/02/2020] >>> Today the first version of the train-track single sensor DB upload script has been made available via GiiHub here: https://github.com/nate-benton90/train_track.git .   Note that you need to have a PostgreSQL DB to use as well as all the necessary Python modules. Also, this script uses Python 2.7 (for now).  This is because the template script provided the RaspberryShake group developed was/is built this way. I may change it to Python 3.7 later on.


***[02/04/2020] >>> Finally managed to connect both Grafana and the simple time-series data stored via AWS RDS PostgreSQL table. See images below for more insight. Although no analytics are being conducted yet (i.e. for train arrival forecasting), after resolving this stage, doing so will be made possible. Here's something really important to note: add the port at the END of the Host string. This is something that held my progress up for a while - simple I know - but that's perhaps the only "gotcha" part of hooking the DB up to Grafana.

Developing Grafana Dashboard & DB Connection

Progress (Part II)

    Grafana Dashboard [released: 02/08/2020]

    This is the first deployment of a stream-to-DB and view workflow for the Train-Track project.

    Train-track dashboard

    Next Steps...

    Real-time seismic waveform analysis

    [02/17/2020] Although data are now being actively stored and subsequently retrieved for dashboard viewing (this also is a seperate challenge as the Grafana one above is snapshot. I'll eventually make one real-time and public facing), I'm now planning what needs to be done in order to effectively gather and analyze the recorded time-series seismic data. What's the point of all that? Remember, we're trying to detect incoming trains and thereby forecast their arrivals further down the track.


    As I see it now, there are two obstacles to this: 1) train signal discernment and 2) wavefront direction/orientation. The first involves accurately evaluating signal (trains) from noise (literally everything else) - this will likely be done with functions from the Python package ObsPy Overcoming the second issue will eventually involve acquiring another sensor and then synchronizing both in order to discern in which direction the train is traveling (yes, it can arrive/leave going from East to West and vice-versa). Work is being conducted now to resolve these upcoming issues.


    [02/19/2020] A lot of work for this project has been delayed - unfortunately - by other activities that I'm involved with. Check back in regularly to see if anything has changed here - otherwise, reach out if you'd like access to data or code from my work.

    Welcome

    If you would like to access and download the a recent miniSEED binary files generated from my sensor, go here to do so:

    GET Seismic