Week 3:

Date: 26 January 2018
Total hours: 12
Description of design efforts:

We decided to go with the stm32f0 discovery board. Then I built the circuit using the micro controller interfacing it with the hcs04 sensors. I learnt how to interface the microcontroller with the sensor. There are basically four pins for the sensors, two of them being the vdd and the gnd. The other two are the trigger and the echo pin which need to be configured properly with the micro controller. We decided to use an interrupt to send a trigger signal and get back an echo signal from the sensors. The pulse width will basically tell us the distance of the stick from the obstacle. ADC will be used to convert the analog signal into a digital one and some manipulations will be done with that data. A set threshold value will determine whether the stick should vibrate to alert the reader. I also helped in writing a code in system workbench to blink a light. We first wrote some code to get ourselves familiarize with the microcontroller. We just wrote a code to make a led(PC8) light up and then tried to blink it. Building on that, we tried to use an interrupt using PA0’s pushbutton to make the led blink every time a pushbutton is pressed. We got that to work. We are planning to use the circuit we built and the concepts that we have gathered from writing the code for the interrupt to write the code for the ultrasonic sensors to work by this weekend.We also spent a lot of time looking at gpio pin configurations and the different registers(eg GPI0x_MODER,GPIOx_OTYPER)associated with it.The website which was useful can be found here. We are also starting to build the app using android studio for the blue-tooth and looking at online tutorials for making the PCB. I along with Shrihari wrote the component analysis. I am also trying to learn the I2C protocol which might be needed for communicating the accelerometer and the gyroscope module with the the stm32f0.

Week 4:

Date: 1st February, 2018
Total hours: 15
Description of design efforts:

Microcontroller- All of us worked on the micro controller. We used this whole week to code the TIMER module. We built the circuit connecting the HCRS04 sensors with the STM32F0 discovery board last week. We got the sensors to work. We spent a lot of time figuring out the correct frequency for the clock.We came up with the prescaler and period value to set up the frequency of the modified clock. We added 1 to the prescaler value and divided that by the internal clock frequency of 48 MHz. We multiplied the clock period with the period value set by us to get the time for one interrupt. I looked at STM32F0 reference sheet to help figure out the different initializations for the different registers. We sent a trigger signal of desired assertion length to the trigger pin of the sensor. We used the Input Capture to capture the signal generated by the echo pin of the sensor. We used both edges to fire an interrupt.We used counters to calculate the length of the assertion time of the pulse. We were able to get a linear relationship between the length of assertion and the distance of the user from the obstacle.We almost got done with our first PSSC.

Plans: We plan to manipulate the assertion values and use the PWM to generate pulses of different frequencies. The frequency of the pulse will determine the intensity of buzzing of the buzzer which is connected to it.

Other things: I looked at the tutorial for PCB and downloaded EAGLE. I am trying to go through the tutorial so that it is easier for us to figure things out when we actually start building the PCB. We also ordered the RN4020 bluetooth module and I am trying to learn and work on the UART interface of the Bluetooth module. I am also helping Shrihari in making the app using Android Development Studio. I also helped in writing the Electrical Overview document for this week. I have slowly got myself involved in the app development as well. This week, I helped Shrihari to design the login page for the app with text views and buttons.

Week 5:

Date: 9th February, 2018
Total hours: 16
Description of design efforts:

Microcontroller:- We got our first PSSC to work completely. We attached the buzzers to the PWM output.Input Capture was used to capture the signal from the echo pin. Both positive as well as negative edges were used to fire an interrupt. The assertion time was calculated using counters. This counter value gradually increased with the increase in the distance of the obstacle from the sensor. We used a constant value and subtracted our assertion values from that to get the value which would be required to generate the PWM output. We wanted more intensity of buzzing as the user gets more closer to the obstacle. We kept different voltage levels and duty cycle for the PWM output keeping different thresholds for the distance between the obstacle and the user. Hence we were able to achieve different buzzing levels for varying distances of the of the obstacle from the sensor.
We decided to use an amplification circuit because there was not a noticeable change in the buzzing for different distances.We also decided to change our duty cycle and voltage levels as well. We used a circuit as shown on the side to amplify the limit of 2.7V to somewhat closer to 5V. We decided to use a 2 npn transistor logic but that was not working well because of supplying a very low current. We took Professor Mithuna's advice and used a simple mosfet circuit using it as a switch. We connected the drain of the mosfet to the buzzer and the source was connected to the ground. The PWM output served as an input to the gate of the mosfet. That made things easier for us and we were able to get a good buzzing change. We finally got done with our first PSSC.
Other Things:- I am also currently working with Shrihari on the app. I am also trying to work on the Bluetooth RN4020 module. I read about the UART. There are two UART ports on our micro-controller STM32f0. We are going to use one of them. There are two pins required. One is for transmitting the data and one is for receiving the data. I tried making a basic circuit to check the functionality of the UART using a FT232 and PUTTY. Its still not working properly. I am trying to learn more about UART and the initializations to make it work. Shrihari is also helping me in doing that. I also helped in the document due for the week.
Plans next week:- 1)Learn about the fall detection system using accelerometer and gyroscope.2) Work and get the UART working as much as possible.3)Understandng GATT servers

Week 6:

Date: 16th February, 2018
Total hours: 15
Description of design efforts:

Bluetooth: This whole week was spent working on the bluetooth module. Shrihari and I worked on the the blue tooth module.Both of us first read about RN4020 to get familiar with it. We decided to use the FT232 to use the serial interface on the computer to communicate with our micro controller. The FT232 has 6 pins but only 4 are important at the moment. The 4 important pins are the RX,TX,VCC and the GND pin. We decided to use the the PA2,PA3 on the STM32F0 to use as the UART module. PA2 is the TX pin and PA3 is the RX pin.Both their power supply and ground pins needed to be connected. Shrihari and I looked at the connections for the STM32. We connected the TX pin of the STM32f0 to the RX pin of the FT232.In the same way we connected the TX pin of the FT232 to the RX pin of STM32f0. For the time being we only need to transmit data. We setup the registers for the UART module using CubeMX. Then we tried transmitting a data using hal built in functions. We were successfully able to transmit a message. For our project we don't need to receive anything on the micro controller for the moment. Then we tried to connect the FT 232 to the RN4020. We had to do some setting changes to the RN4020 using George's guide page. We were able to transmit data and see it on TERA TERM. We downloaded an app called SmartData for trying out the communication. We connected the RN4020 with the FT232 using the same analogy. It worked out fine as well and we were able to send data from tera term and receive it on the app.At last we connected the RN4020 to our STM32f0 and we were able to receive data on the app from the microcontroller using a baud rate of 115200. This is the first step towards building the S0S button connection to the app. Ruchir worked on PCB design. Shrihari and I helped him with blue tooth connection.We are almost done with one more PSSC.
Plans next week: Work on the app and try to integrate it in our design and use interrupts to read the SOS button input.

Week 7:

Date: 23rd February, 2018
Total hours: 15
Description of design efforts:

Things done this week: This week was mainly focused on doing the PCB to get it checked by the professor and the TA's before sending it out. Ruchir worked on the PCB. We also decided which connections to use for the accelerometer on the PCB because we have not implemented the accelerometer and the gyroscope yet. We also faced a problem with our ultrasonic sensors as we were not getting a change in the duty cycle and the voltage as an object was kept at various distances from the ultrasonic sensors. It took us some time to figure out that problem and we realized that we were not using the correct mask value for a GPIO pin as we have changed the pin. We had to change the pin because there was conflict in using the same pin for the UART module as well. Shrihari, Gautam and me spent some time looking at the I2C peripheral. We have to use it to have communication between the STM32F0 and the mpu6050. I spent some time with Shrihari in figuring out the connections for the mpu6050. We want to use the STM32F0 in master mode which would acquire data from MPU6050(slave) depending on the angular position of the device.We decided to use PB6 and PB7 for the I2C.There are two HAL commands transmitting and receiving data. We also learnt that every device has a 7 bit address which would be required here to send as a parameter for the HAL functions. We have to use HAL_I2C_Master_Receive(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout) function and we have to choose the correct parameters.
Plans next week: Work more on the app and try to finish the bluetooth PSSC as much as possible.Also we should finish our PCB completely so that we can sent it out before spring break.Work on the accelerometer and gyroscope PSSC as well.

Week 9:

Date: 8th March, 2018
Total hours: 15
Description of design efforts:

Things done this week: This week I worked with Gautam and Shrihari on the mpu6050 accelerometer and gyroscope. mpu6050 is a tri axis accelerometer and gyroscope.We used pins PB6 and PB7 for I2C communication with the mpu6050. The PB6 is a serial clock line going from the STM32F0 to the mpu6050. PB7 is connected to the serial data line(two way line) going to the micro controller. We connected the oscilloscope to the serial data and the serial clock pin to debug.We used the HAL_I2C_Master_Transmit() and HAL_I2C_Master_Receive() to develop communication. We had to first figure out the various useful registers using the data sheet of the mpu6050. We woke up the mpu6050 using HAL_I2C_Master_Transmit(&hi2c1, MPU6050_ADDRESS, data, 2, 100). The address of the mpu is 68 is hexadecimal. The data is a 2 byte uint8_t number where the lower bit contains the address of the register we want to write to and the upper bit contains the data which we want to write. In the same way we actually read values from the registers which contain the accelerometer and the gyroscope values.For reading we have to first use the transmit and then the receive function. We read three axis values from registers having addresses from 59-64 for the accelerometer and 67-72 for the gyroscope. Each axis value is 2 bytes long. We had to use single byte to read the MSB and the LSB separately and then use shifting and anding to combine it to one number. We also changed the range of the values by writing to a register. Now we are trying to come up with an algorithm to detect a fall. We are trying different types of algorithm to see which one depicts the fall in the most accurate way. We also need to do some complicated math for which we might need to add separate math libraries unless we come up with an easier solution. We are almost done on the PCB as well. Ruchir is making the final changes and we are going to sent it out this week.
Plans next week: Work more on the algorithm and try to implement the snooze button as well. Also work on the app and try to finish it.

Week 11:

Date: 22nd March, 2018
Total hours: 15
Description of design efforts:

Things done this week: After coming back from the spring break, we finally got our PCB on Tuesday. We spent some time looking up the parts(eg micro-controller, rn4020 microchip etc) along with the resistors and capacitors. We already ordered them using the fastest shipping method and as soon as they arrive, we will start soldering the parts on our PCB. I also worked on the fall detection algorithm. The mpu6050 provides us with tri axis acceleration and angular velocity values. We decided to use both these parameters for detecting whether a fall has occurred or not. We decided to come up with the with the following flowchart as shown in the above diagram. We will try to manually find acceleration and gyroscope threshold values depending on the speed with which the stick can fall and also depending on the angular position of the stick. We decided to use a very simple algorithm at first to test. We decided to find the normalized value by finding the square root of the sum of the squares of the tri axis values for both the accelerometer and the gyroscope.The two normalized values are the one that we would want to compare with our threshold value.We would use a nested condition by first comparing the normalized value for the accelerometer with the manually calculated threshold value. If the normalized value is less than the threshold value we would not do anything and go back and collect new data. But if the normalized value is greater, we would check the normalized value of the gyroscope with the manually calculated threshold value of the gyroscope. If the normalized value is lesser , then we would go back and collect new data, else we would have a delay of 2s and then again check for the gyrocope value condition. If the normalized value is still greater, then we would call it a fall. We are checking the angular position two times having an addition 2s delay in the middle to make sure it is not an accidental fall or movement and a real fall has actually occurred. We are done with writing the code and we are still figuring out the accuracy of the algorithm by changing the threshold values. Since we are almost done with most of the major parts of out project, we want to spend some time working on the algorithm to make it as accurate as possible as it is really difficult to distinguish between actual and false falls.I am also helping Shrihari on working on the app. Gautam has already ordered the parts.
Plans next week: Try to implement the SOS button. Also implement all the functionalities together with the PCB to see if everything is working together and set interrupt priorities.

Week 12:

Date: 30th March, 2018
Total hours: 15
Description of design efforts:

Things done this week: This week we finally got the parts for the PCB from the Bill of Materials. Gautam, Shrihari and I worked to get the whole system working. We soldered the required parts (eg. Microcontroller, mpu, rn4020, resistors, capacitors etc.). Since we were not experienced in that, it took us quiet a bit of time to finish that work in a clean and tidy manner.We also spent quiet a bit of time wiring the things with long and colored wires for our understanding. We had to make use of long wires and tape it firmly to run some more tests with the mpu as our PCB was not ready yet. It was essential for making sure that nothing comes out while calculating thresholds for the accelerometer and the gyroscope. We also tested the entire system while putting all the code together.The fall detection, SOS and the ultrasonic sensor works perfectly together. That also took us quiet a bit of time to debug and fix when we put everything together. We are also working on the app. We are able to scan devices as well as connect to the device of our choice by selecting the appropriate index number. We are working on receiving data and manipulating them to use it to send emergency texts.We had to create BluetoothGattCallback for connecting to a peripheral device far away. We called connectGatt(Context, boolean, BluetoothGattCallback) to get an instance of the class. Plans next week: 1)Test the entire system with the PCB.2)Finish the app.3)Packaging plan.

Week 13:

Date: 6th April, 2018
Total hours: 20
Description of design efforts:

Things done this week: This week we worked extensively to get the parts on the PCB working. We had to spend a lot of time debugging and soldering parts on our PCB as well in addition to using breakout boards to test the functionality of the various parts. We have our parts soldered onto two PCB boards. That took us lot of time. We checked the connectivity using the DMM to make sure that the parts are soldered on properly. We made use of the oven under the supervision of George Hadley to get the mpu soldered on to our PCB. Above is a picture of the xray of the soldered part. We finally got our Ultrasonic sensor and buzzer to work by programming the micro controller on the PCB. That satisfies two of our PSSCs. We were finding it hard to program the RN4020. We tried to debug a lot and we couldn't find out the issue. Hence we decided to change our Bluetooth module to HC-05. We borrowed the breakout board and the part for the PCB from one of the groups and built the circuit to test. We were successfully able to transmit messages using the breakout board. We then changed the settings for the HC05 for changing parameters like baudrate, name etc by connecting it to the FT 232 and sending AT commands using the serial interface. We used the HC-05 official android app to connect to it and receive data. We were able to make it working on the PCB as well. We are still working to get the mpu working on our PCB. Meanwhile we are also working on our app. We have to make modifications to our app because previously we were making it for BLE devices but now we have to make it for normal bluetooth devices. We also ordered a new PCB with the new HC05 part on it and we also added extra debugging headers to help us.
Plans next week: 1)Make the whole PCB functional 2)Finish the app.3)Start packaging.

Week 14:

Date: 13th April, 2018
Total hours: 20
Description of design efforts:

Things done this week: This week towards the beginning, we were busy debugging the mpu-6050. It was not working at first and we tried to debug a lot by doing all sorts of tests. At last we realized that we connected our two resistors R5 and R6 on the PCB in the wrong fashion which made the SCL line connected to the SDA making one open and the other short. We corrected that and soldered the resistors again. That got the mpu to start working. We also wired up everything properly as shown in the figure above to test our entire system on the PCB. Everything works perfectly. We also finished building our app. It also works properly. It is successfully able to connect and receive proper messages for SOS and fall detection for the registered user. We have also ordered a new PCB along with a stencil to make two more copies with the new HC-05 bluetooth module. We also ordered a stencil this time for making it easier for soldering.We are currently working on packaging and working on CAD. As soon as we finish that we will 3D print our box and test the system again.We got all our initial PSSCs checked off as shown in the figure.
Plans next week: Finish packaging.

Week 15:

Date: 20th April, 2018
Total hours: 20
Description of design efforts:

Things done this week: This week was mostly devoted in making new copies of the PCBs along with working on packaging as well. Lot of time was spent on making new copies of the PCB. Lot of time was devoted to soldering and making connections. We also spent a great deal of time finalizing our packaging design in cad. We had ordered the 3D print material and also put in our name at Walc for 3d printing. By Saturday our box will be 3D printed. We also had to spent some time debugging the circuit as our new HC-05 was not working at first. Then we had to reverse the TX and RX lines as we noticed that we had put them in the wrong order on our PCB. After that everything started working. Now we have two extra PCBs in case anything goes wrong. We are just waiting for packaging to be done and then we will be ready to display our product. We are also working on the app to make it look more attractive and appealing. We are trying to make it as user friendly as possible. We are also trying to make the code for our fall detection system as accurate as possible by changing thresholds and testing it.We are also trying to keep everything ready so that as soon as the 3D printed box comes, we can be ready to demonstrate.
Plans next week: Make last minute changes and be ready to demonstrate.

Week 16:

Date: 27th April, 2018
Total hours: 15
Description of design efforts:

Things done this week: This week was the last week. We went to electronic store and bought all the necessary things for packaging. We finished packaging and tested our entire system. We also polished our app and threshold values for the mpu6050. We got checkoffs for all our final PSSCs.