Difference between revisions of "F16: Seismograph"

Latest revision as of 00:45, 24 December 2016

Project Title

Abstract

In recent years, news of an upcoming large scale earthquake in California has been increasing. Having a seismograph would allow us to directly see any seismic activity. In addition, by adding an LCD screen, we would be able to add plots of the data in a time series manner for any research purposes. Most importantly, the seismograph device would allow to help with search and rescue efforts. When a large scale earthquake is detected, it would allow a signal to be detected via your cellphone in order to ping your GPS location in case of a building collapse.

Objectives & Introduction

Our seismograph would help bring awareness to the realities of earthquakes in California. In addition, it has the possibility to help save lives by aiding in search and rescue efforts when a large earthquake is encountered.

• Create a working seismograph and store data onto a microSD card
• Write software to display data onto an LCD screen
• Add to software to send signals to cellphone via Bluetooth
• Write a small mobile application to receive data via Bluetooth

Team Members & Responsibilities

Both team members will be working on all areas of development with specific focuses as follows:

• Mina Yi
  • Focus on software
    • Display data on LCD screen
    • Mobile application to recognize signal
• Andrew Ahwal
  • Focus on hardware portion to build a working seismograph

Schedule

• Responsibility and leadership of the task is indicated by the Assignee.
  • However, it does not mean that they will be expected to complete the tasks alone.
• Subtasks are listed in the comments section and are numbered.
• Subtasks will be delegated as seen fit.
• Any deviation to the schedule due to technical issues will be covered under the Testing & Technical Challenges section.

NOTE: Documentation is not specifically listed in our project schedule. However, each task has a documentation phase before and after each task.

Parts List & Cost

Design & Implementation

Hardware Design

The seismograph is constructed using two separate circuits. The first circuit illustrated below labeled Seismograph Circuit is the sensor circuit which detects an earthquake and creates a voltage. This is done by a piezoelectric sensor that generates a millivolt signal whenever a vibration or seismic activity is detected. The piezoelectric sensor has a positive and negative terminal, which connect both terminals directly to the LM324N amplifying circuit.

We created two amplifying circuits with feedback to intensify the signal that is generated to approximately 2.5 volts. When the signal is first made it is too small to be read by the ADC hardware thus we needed to step up the voltage to a more applicable range. At this stage the voltage varies from 2.5 volts at a steady state when no seismic activity is detected. Once a vibration occurs causing the piezoelectric sensor to vibrate, the voltage will drop to approximately 0 volts. A low pass filters is used to reduce noise from the signal so we can receive a clean seismic signal when a vibration is felt by the piezoelectric sensor. The output of this portion of the circuit is an AC output which has a positive and negative direction for voltage. It is unfavorable to use this signal thus we use a rectifying circuit to create a steady DC voltage output.

Seismograph Circuit

The second circuit is a rectifying circuit which takes in the 2.5 volt output that is generated from the Seismograph Circuit. The purpose of this circuit is to cut off the negative voltage and create only a positive voltage. This voltage that is outputted is what we connect directly into our A2D converter which is developed in the SJONE board. Once the voltage goes through this rectifying circuit, we are left with a zero volt output which raises whenever a seismic activity is felt.

Stage 2 Rectifying Circuit

The following figure illustrated below is a complete pin schematic of the entire seismograph.

Seismograph Pin Schematic

The following picture illustrates below is the wirewrapped seismograph board.

Wirewrapped Seismograph

Hardware Interface

When constructing the Seismograph, we needed to incorporate many system interfaces for communcation between the different modules. The following interfaces and technologies were used in constructing the Seismograph and are illustrated below.

Technologies Used

Mobile Application

• Apache Cordova
  • GeoLocation
  • Bluetooth

Protocols, Hardware, and Peripherals

• SPI
• UART
• Bluetooth
• ADC
• 1.8" TFT LCD Screen

Apache Cordova is the framework used to construct the android app for the seismograph. The androids app main purpose to connect directly to the HC-06 Bluetooth module using a Bluetooth communication. Once the communication is established, messages can be sent back and forth between the SJONE board using UART communication which is then converted directly into a Bluetooth signal. We implemented this feature into the seismograph to allow for the SJONE board to determine the GPS location of the host user and relay it back when an earthquake happens.

Photo of our GPS and earthquake alert

The 4-line SPI interface was used to communicate between the SJONE board and the Adafruit LCD shield. The purpose of this interface is to initialize the board with startup configurations such as register setup and to send the earthquake data to the LCD to be drawn for a graphical representation. When we designed the hardware driver for the SPI communication we used SSP1 and used the following pins for each configuration as illustrated below in the table.

The UART communication was implemented to communicate between the SJONE board and the HC-06 Bluetooth module. This was done using a 9600 bps baud rate with the basic configuration. We use the UART communication to send data back and forth between the HC-06 Bluetooth module. The Bluetooth modules main purpose is to be able to connect directly wireless through a Bluetooth communication to our android phone app. Once an earthquake is detected from the seismograph, the SJONE board will send data directly using the UART communication to the HC-06 at which will be sent directly through the Bluetooth link between the HC-06 and the cellular android phone. The pin configuration between the SJONE board and the HC-06 Bluetooth module are illustrated below in the table.

The analog-to-digital converter was implemented to interpret an analog signal that is generated from our seismograph circuit. This circuit will take in a voltage range from 0 volts to 2.5 volts and convert it into a 12-bit hexadecimal value. This is how we interpret when seismic activity occurs and make sense of the data to the SJONE board. The pin configuration between the SJONE board with the built in ADC is illustrated below in the table.

Software Design

The software design consists of 3 main tasks. The LCD task, ADC task, and the Bluetooth task. The ADC task continuously samples data from the seismograph and converts the analog signal to its digital counterpart. It then writes the data received along with a running time stamp (given in ms). The data was divided to an 8 bit value to scale it down for plotting on the LCD screen. The time stamp and the ADC value make up one (x,y) plot on the screen where timestamp is our x value and our 8 bit digital value is our y value. Lastly, the Bluetooth task waits for a signal from the ADC task to send a message to a mobile application.

LCD Task

The LCD task handles all of the drawing of the seismograph data to screen. Below is a flowchart of the design used. The LCD task uses SPI protocol to send data received from the queue to be drawn onto the screen.

LCD Draw Flow Chart

The LCD task follows the diagram above and to prevent wrapping and drawing over previous data, we clear the screen when it is at the end and continue drawing. The LCD task uses an internal state machine to draw lines between the points. It takes the initial x0,y0 value and draws a point to the next x1,y1 point. When it continues, it makes the last point the new starting point and continues to draw as it receives values.

The steps to draw pixels to the LCD screen are as follows:

Set the address window:

1. Send CASET command
2. Send the column address value (this is our x value)
3. Send command opcode
4. Send the row address value (our y value)
5. Send the RAMWR command to write to the LCD memory

Set the pixel:

1. Send the RAMWR command
2. Send our RGB 565 color value

Each time a command is sent, the our DC pin is cleared since it indicates that the value sent is a command. When we send our data, we pull the pin high by setting it to indicate we are sending data.

As described in the Testing and Technical Challenges section under Working with the ST7735: Setting Our Origin Point the column and row addresses are swapped because it was originally intended for portrait display.

LCD State Diagram

ADC Task

The ADC task converts the data from the seismograph to a digital value and stores it into the SD card as well as providing the value via the freeRTOS queue to the LCD task. A mutex was necessary since both writing to the SD card and LCD screen use SSP1 for transferring data.

The data stored on the SD card is in the format (time, ADC value).

Suggestion: API for ADC is provided under adc.c and could have been used.

Bluetooth Task

The Bluetooth task is used to send an "Earthquake" message to a mobile application via UART. It utilizes a binary semaphore that gets triggered when an earthquake with a value above hex 0xB00 is detected.

HC-06 Bluetooth Module with PIN Descriptions

The mobile application has an event listener that waits to receive a newline (\n) via UART. When it receives it, it prints the message that follows and then brings up an alert window that displays the current GPS location.

Mobile Phone Application User Interface

Implementation

Our overall system implementation consists of the following steps:

1. The seismograph sends data to the SJOne board that gets converted to a digital value
2. The 12 bit ADC value is checked to see if it is equal or greater than 0xB00 (this value was obtained through expirementation). If it is true, it signals the bluetooth task to send out the earthquake message via UART.
3. If the mobile application receives an earthquake message, an alert appears on the screen with the GPS coordinate information
4. The value is sent to a shared queue
5. The LCD task receives values from the queue and following its state machine, it draws the values to the screen

Testing & Technical Challenges

Working with the ST7735

Poor Documentation

There were problems initializing the LCD screen due to poor documentation. The only provided documentation for the screen itself was given in Chinese so it was very difficult for us to figure out how much voltage the screen required for power on. In order to figure this out, we connected an Arduino and cross referenced each pin and voltage that was required to power on the screen. We ended up having to read through code originally intended to work for the Arduino to understand the initialization process of the LCD screen.

Setting Our Origin Point

The ST7735 appears to originally be configured to be used in portrait mode with origin located at the upper left hand corner. In order for us to use draw in landscape with the (0,0) pixel at the bottom left hand corner, we swapped the width and height values (originally 128x160). We then found that it still did not start where we expected it to but instead, the (0,0) mark was on the top left hand corner in landscape view. So, when we drew the pixels, we subtracted the y value by 127 to shift the values down.

Continuous Real-time Drawing
We needed a way to have our LCD screen continuously draw between x,y points we received. We began with points but found it difficult when we needed to draw a line from point to point. In order to help with this, we created a state machine that runs internally to the LCD task. This way, the last x,y points were taken as the new current x,y point to have a continuous line.

Bus Contention Issues

Since both the LCD screen and the SD card were using SSP1 for SPI communication, we had issues where the LCD screen would suddenly turn to an all white screen. We came to the conclusion that since they were using the same lines, there was bus contention. In order to solve this problem, we utilized a mutex to ensure that only one of the tasks was utilizing the line at any given time.

Conclusion

In conclusion, we were able to successfully complete our project. We built a working seismograph and interfaced it with multiple components utilizing the different communication protocols we learned in lab. This project helped solidify our knowledge and understanding of not only how important datasheets are, but how important it is to read them and understand how to read them. We found that due to poor documentation, it made it very difficult for us to actually get things working in a timely manner. We ended up sinking a great amount of time trying to figure out how to initialize the LCD screen and what voltages it expected to even turn it on. In the end, we learned a great deal implementing our project and were able to solidify our understanding of many of the things we learned during our laboratory lectures.

Improvements

In the future, we would improve on this project by implementing a joystick that would allow us to scroll through the data history. A great deal of research was done to try to get this working. We were able to detect the movements of the joystick but realized too late that we were unable to use the ADC at the same time as the seismograph. This is because, as stated in the manual, when using a software ADC, you can only have values converted in one channel at a time. This meant that we would need to use interrupts to use multiple channels. We also came to the realization too late that these interrupts are actually already implemented in the API provided to us in adc.c. This is a great example of "never reinvent the wheel" and to always read thoroughly any documentation for any limitations.

In addition, the project could be greatly improved upon if we were able to do extra research in getting accurate readings. Essentially, how do we know what voltage corresponds to what magnitude earthquake? In this project, we had to make some estimations and testing based off trial and error to find a value that fit, but we could increase the accuracy of this design through further testing and research.

In terms of the mobile application, it currently just receives a message and prints it to screen and a pop up appears with the GPS location. In reality, this would be useless. It would be far more useful to be able to integrate this application with another social media platform like Twitter or Facebook to allow loved ones to know where you are and for people to be able to respond whether they are safe.

Project Video

Seismograph Demo Video

Project Source Code

Seismograph GitHub Repository

References

Acknowledgement

A special thank you to the following individuals for their help, guidance, and answering our never-ending array of questions:

• Preetpal Kang
• Praveen Prabhakaran
• Charles MacDonald
• Dr. Ozemek

References Used

List any references used in project.

• ST7735 Datasheet
• Building A Seismograph
• Apache Cordova Documentation
• LPC176x/5x User Manual
• LPC1758 SJOne Board Rev4 Schematics
• freeRTOS Documentation