Progress Report for Ruchir Aggarwal

Week 1:

Date: -Enter today's date here-
Total hours: -Enter the number of hours you worked this week here-
Description of design efforts:
-Discuss your design efforts here. Remember to follow the guidelines presented in the Progress Report Policy, available here. This is a template entry; simply copy/paste this entry when doing progress reports each week.

Week 2:

Date: 19 January 2018
Total hours: 10
Description of design efforts:

Since we changed the entire project in the first week, most of the work in this week was the research conducted on the various parts to be used in the making of the new design. Primary focus was put on selecting the microcontroller. After the lecture, the final decision was made to use STM32 microcontroller since this microcontroller was powerful enough to perform all the computations we needed and much more. I was responsible to work on the Thermal/Power and mechanical constraints in particular. So I spent a lot of time on writing the functional specifications. I also helped in creating the functional block diagram for the SensoStick so that the team can work in a much more streamlined manner. The diagram is shown on the right:

I spent sometime figuring out how the gyroscope and accelerometer worked together to detect fall efficiently. I found one such paper here. Although the paper is based on smartphone, the procedure and equations for better accuracy can be referenced. We already have ordered the ultrosonic sensors. So our next course of action is to figure and calibrate these sensors so that we can find the eqations for the distance and build a circuit to affectively connect the sensors to the microcontroller. Since we borrowed a STM32F7 kit from Joe Bougher, we will try to connect the sensors to the microcontroller.

Week 3:

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

A good amount of was spent to finish the Software overview document. Research was done for finding the data dstructures required in our design. So the result was that there is a requirement of two data structures, one for communication between microcontroller and MPU-6050 sensors and the other one for communication between the microcontroller and the HC-SR04. Further research was done to learn the working of I2C communication protocol for interfacing of MPU-6050.
I read and did tutorials on STM32 Dev board. A significant time was spent on understanding the ins and outs of the GPIO. The resources that I found and used were:

1. Understanding the STM32F0's GPIO part 1
2. STM32F0 TUTORIAL 1 – GPIO

I learnt a lot from the tutorials including about the 5 ports in the Dev Board. Also, I learnt that all these ports are gated and I need to specifically tell the microcontroller to route the clock to a particular gate. Also, I learnt the purpose and how to use different registers in a particular port like MODER(Mode Register) is used to change the mode of a particular pin. To explain further, changing the mode of the PC8 of GPIOC to '01' sets the pin to output mode due to which we are able to light up the LED on the dev board. Not setting the pin to output mode would not cause the LED to light up. Similar observations were made for other registers like ODR(Output Data Register) etc.

Hence, based on the knowledge gained, I made the lights on the dev board light up alternatively. Furthermore, I, with the help of my team, was able to get an external interrupt from the pushbutton and make the PC8(LED) light up when the push button was pressed. We did this because we need to get an interrupt from the timer module after every fixed time to read the signal from ultrasonic sensor. So to make the interrupt work was important. However, now we need to get the interrupt from Timer module, which is the target till next wednesday. Following above, I helped in making the circuit to interface the HC-SRO4 sensor with the STM32 microcontroller. However, coding for the same is still in progress.

Week 4:

Date: 2 February 2018
Total hours: 14
Description of design efforts:
Primary work done during this week was the interfacing of the ultrasonic sensor with the STM32 microcontroller. It involved two major taks:

• Generate an interrupt using TIM module: The first step taken was to send a trigger signal to the trigger pin of the HC-SR04 sensor. The sensor requires a trigger with a width of 10 microseconds. The trigger needs to be send after every 0.1 milliseconds. This allows for a quick check for obstacle detection and provides response to the user. For this me and Gautam figured out the correct period(100,000) and pre-scalar value(=479) to get the correct interrupt.
• Read the width of the sensor output using input capture mode in TIM module: Once the trigger was successful generated and sent to sensor, the echo was received and seen on oscilloscope.The images present here are for object at close, medium and far distance from the sensor. As the distance from the sensor increased, as shown in the pictures, the width of the pulse sent by the sensor to the microcontroller increased as well. This width of the pulse is actually the time taken by sound to go from sensor and get back after getting reflected from the object. From the width of the pulse and using the formula: Distance = (Speed of sound in air * Width of the Pulse) / 2, I was able to verify that the sensor was correctly interfaced with the STM32F0 Discovery board.
  
  
  
  
  
  
  
  
  
• For the next week, we need to make the buzzers to vibrate based on the input received from the HC-SR04 sensor. Our intention is to make the buzzer vibrate faster as the obstacle comes closer to the sensor. I will be doing this using PWM.

Week 5:

Date: 9 February 2018
Total hours: 13
Description of design efforts:
This week involved getting the buzzers to work through the PWM generated using the output from HC-SR04 sensor. :

• Generate PWM using Microcontroller: Once the output from the HC-SR04 sensor was received, the distance between the sensor and the sensor was calculated and the time taken for sound wave to get back was also found out using the input capture of the TIM module. Based on this time, we divided the duty cycle into 10 buckets, each about 0.4V (Since, the motor starts running from 1V and the maximum voltage we supply to buzzer is 5V giving us a range of 4V). If the object is really close, then the duty cycle will be close to 100% while as the object goes far, the duty cycle reduces in magnitude. In the image below, the duty cycle is quite high since the diary(acting as an obstacle) is very close.
  
  
  
• Make Buzzer vibrate using PWM: Once my teama was successful in generating the PWM with the right duty cycle, te buzzer was connected to the PWM output. However, since the PWM output was roughly 2.8 V while the motor of the buzzer started only at 1V, we needed to build an amplification circuit to bump up the voltage from 2.8V to 5V to get the full use of the buzzer. I made the circuit as shown in the image below:
  
  
  The above circuit was made using BJTs which failed. However, after consulting with Prof. Mithuna, we were able to create a working circuit using a MOSFET.
  
• For the next week, we need to work on setting bluetooth connection with the microcontroller. Also, we will be working on the PCB layout on Eagle.

Week 6:

Date: 17 February 2018
Total hours: 8
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB Layout: I spent a great deal of time on completing the EAGLE CAD Tutorial. Following the tutorial, I collected the datasheets for all the parts and calculated the resistances and capacitor values. I had to spend some time to collect the part libraries for all the individual hardware components. I was able to get the libraries for all of them. As shown in the picture below, these are the major components required with the connections for HC-SR04 Ultrasonic sensor and Bluetooth module (Since we were able to integrate them already). Gautam helped me with making the right connections on the PCB. Also, after talks with Prof. Mithuna, I came to know that the gyroscope and accelerometer (MPU-6050) can be directly put on the PCB board and there is no exgternal pin header required for it. He also recommended us to do all the computation on stm32f0 since it is very powerful and avoid the use of arduino or raspberry pi. My team agreed to his recommendation and now we are only working with a single stm32f0.
  
  
• Bluetooth Module: Gautam, Shrihari, and Sourjya worked on the RN-4020 Bluetooth module. They sucessfully set up the UART and were able to transfer data from STM32f0 to the receiving pin of RT232 for testing purposes. They then were able to connect the RN-4020 to RT232 as well. Overall, they made quiet a significant progress in the bluetooth module functionality.
  
  
  
  
• For the next week, we need to work on getting the final PCB Layout set up. Also, we need to wok on finishing the mobile app and get it to work with the bluetooth module. In addition to that, we received the gyroscope and accelerometer today, we will be working on the fall detection system as well.

Week 7:

Date: 23 February 2018
Total hours: 12 - 15
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB Layout: Most of the time for PCB Layout was spent on making the correct connections on the schematic. Gautam helped me with the correct connections for Buzzer and HC-SR04. Shrihari and Sourjyo helped me witht he correct connections of the bluetooth module and the MPU-6050. I figured out the connections for the voltage regulators. Also, we missed a few libraries and imported few wrong libraries, which after talking to Prof. Mithuna, we corrected them.
  
  
  
• Fall Detection System Research: I primarily did the research on how the gyroscope and accelerometer work. Gyroscope measures the angular rate while the accelerometer measures force(not acceleration) along a particular axis. For example, the accelerometer in image below, will show a reading of Rx = 0g, Ry = 0g, and Rz = -1g because the force is exerted towards -z axis dure to the force of gravitation. So, we will read a value of (0,0,-1) from accelerometer on MPU-6050.
  
  
  In addition I also researched how to set up and then control data flow in the MPU-6050. I learnt that the MPU-6050 can be interfaced with SPI or I2C but my team decided to do using I2C. I had to go through the datasheet and manual for MPU-6050 to understand the structure of the internal registers in the MPU-6050. For example, the sensor readings from Accelerometer is stored in regs 59-64 while for gyroscope, the sensor readings are stored in regs 67-72. 6 registers hold 3 values, 2 bytes for sensor reading along one particular axis, x,y or z. I also learnt how my team can change the sample rate of the MPU-6050 by controlling the register value of reg 25, otherwise called as Sample Rate Divider(SMPLRT_DIV). It uses the equation:
  
  Sample Rate = Gyroscope Output Rate / ( 1 + SMPLRT_DIV )
  
  I also spent great deal of time to understand the I2C protocol for the MPU-6050. How the read and write sequences actually work and how my team can make it work.
  
  
• For the next week, we still need to add few missing pull-up and pull-down resistors and connector for programming to microcontroller which we will finish by tomorrow. Our next step is to make the fall detection system to work i.e. to interface the MPU-6050 with the microcontroller.

Week 9:

Date: 9 March 2018
Total hours: 20
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB Schematic and Layout: Based on the feedback received from the midterm design review and from Dr. Hadley, I worked primarily to address the issues in the PCB schematic and layout. For example, the schematic was really confusing before. Dr. Hadley suggested me to use nets and signal names to reduce the wire congestion in the scematic. The result was that the schematic, which was earlier like in left image, now changed to schematic in the right image. As anyone can see, the schematic looks much more cleaner and the signal names helped in identifying which pin of the micro-controller is connected where on the board.
  
  
  Then in the layout, I tried to make a new layout from scratch. After looking at the PCB layouts of other teams, I got an idea how to place components better on the better. Also, Dr. Hadley gave my team a detailed and valuable feedback on the layout. So, I tried to correct the intial mistakes made. For example, I changed the through-hole resistors and capacitors to surface mount according to Dr. Hadley's suggestion.

  Old PCB Layout

  New PCB Layout

  Following all other suggestions, the new PCB Layout looks like in the image above. The size of the PCB was reduced from 5in X 8in to 4in X 4in. Also, the desity increased quiet significantly compared to the old layout. I added the decoupling capacitors and changed the width of the traces as well. After getting any final concerns from Dr. Hadley, we ordered the PCB today.
  
• For the next week, we will be continuing our work on the Fall-detection system and the mobile app.

Week 11:

Date: 26 March 2018
Total hours: 7
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB: We received our fabricated PCB, and now whats left is the soldering of individual components on it. The list of parts was made by Shrihari and Gautam. I provided assitance to them since I was the primary person responsible for the PCB. We expect the parts to arrive next week and we expect to finish the soldering by the end of next week.
  

  Fabricated_PCB

  
  
• Fall Detection Algorithm: Fall Detection algorithm is a bit hard and complicated to implement which is why my team left it for the last. Now, after careful research, I have come across 3 potential algorithms for our design:
  • Novel Fall Detection Algorithm: This fall detection algorithm uses two gyroscopes and two accelerometers, one at the top of the stick and one at the bottom. After taking readings, the values are calculated based on formaulas:
    a(1) = sqrt((ax(1)^2) + (ay(1)^2) + (az(1)^2))
    a(2) = sqrt((ax(2)^2) + (ay(2)^2) + (az(2)^2))
    b(1) = sqrt((bx(1)^2) + (by(1)^2) + (bz(1)^2))
    b(2) = sqrt((bx(2)^2) + (by(2)^2) + (bz(2)^2))
    In addition to above readings, the angles of acceleration are calculated. After considering all readings, the detection is made.
    Citation: Q. Li, J. A. Stankovic, M. A. Hanson, A. T. Barth, J. Lach and G. Zhou, "Accurate, Fast Fall Detection Using Gyroscopes and Accelerometer-Derived Posture Information," 2009 Sixth International Workshop on Wearable and Implantable Body Sensor Networks, Berkeley, CA, 2009, pp. 138-143. doi: 10.1109/BSN.2009.46
    
    
  • Complex Threshold Based Algorithm: A more complexed algorithm is based on the same calculated values of accelerometer and gyroscope as above. Apart from that, we have to calculate specificity and sensitivity which help in eliminating false negatives. In addition, something called Zero crossing also needs to be calculated which is a function of current and past readings. Based on these readings, the fall detection was made.
    Citation: Khowaja, S. A., Feri, S., Aria Ghora, P., Bernardo Nugroho Yahya1, b., & Seok-Lyong Lee1, s. (2016). AN EFFECTIVE THRESHOLD BASED MEASUREMENT TECHNIQUE FOR FALL DETECTION USING SMART DEVICES. International Journal Of Industrial Engineering, 23(5), 332-348.
    
    
  • Neyman-Pearson Detection Algorithm: This algorithm is based on realizing the differences between different activities like walking, running, sitting etc. Generally, the difference between activities, in terms of fall detection, can be found from the sudden change of acceleration. For example, when something falls, there is a sudden increase in the acceleration in the opposite direction as the pointof contact witht he ground is made. This principle is indeed used here to differentiate between different physical activities for detecting fall.
    Citation: Y. Li, G. Chen, Y. Shen, Y. Zhu and Z. Cheng, "Accelerometer-based fall detection sensor system for the elderly," 2012 IEEE 2nd International Conference on Cloud Computing and Intelligence Systems, Hangzhou, 2012, pp. 1216-1220. doi: 10.1109/CCIS.2012.6664577
    
    
• For the next week, we will finish our Fall-Detection algorithm, based on one of the above algorithms, and its testing along with soldering of parts on the PCB.

Week 12:

Date: 31 March 2018
Total hours: 8
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB: We soldered the components(except the pushbutton and debugging headers) on the PCB and tested some individual components to check whether the soldering was correct and the microcontroller was getting programmed or not. The image on the bottom shows how the PCB looked after soldering.
  
  Below is the list of our testing:
  • LED: We connected an LED to PC8 of our microcontroller. Once we tried programming our microcontroller on the PCB, the LED was lighting up properly.
    
  • HC-SR04: For distance sensor, we tested whether the trigger to sensor and echo from the sensor were working correctly. The readings were good.
    
  • Buzzer: After testing the readings from the HC-SR04, we tested the buzzer whether it vibrated at te correct intensity with changing distance and it was a success as well.
    
  • Bluetooth: We are currently having issues with bluetooth connectivity with our microcontroller on the PCB. so we are still testing it.
    
  • Accelerometer, Gyroscope: We haven't tested the accelerometer and the gyroscope with our PCB yet.
    
  
  

For the next week, we will make minute changes to PCB and reorder based on our extensive testing we will do over the weekend. If there are no changes required, we will solder another PCB based on our current design.

Week 13:

Date: 6 April 2018
Total hours: 15
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB: After our testing of other components, which include Bluetooth and Accelerometer and gyroscope, we weren't able to use bluetooth RN-4020. Hence we decided to change the bluetooth chip on our design. Now we are using HC05 instead, which we managed to get to get to work with the old PCB design. On the other hand, we were able to make the accelerometer and gyroscope work with the breakout board. However, it wasn't working with our PCB. We realised that we missed 1-2 connections which we corrected. However, we still need to test the corrected circuit. After testing, we made changes to PCB and ordered it again(with much more density taht last time). The changes I made are as follows:
  
  
  • Bluetooth: Replaced the RN-4020 with HC05. The layout and schematic for the bluetooth added are shown below:
    
    
    
  • SOS and SNOOZE buttons: On our old design, we forgot to add the headers for these buttons. Hence we added them to the current PCB design.
    
    
    
  • MPU: MPU circuit was missing one capacitor (C1) and there was a connection correction (FSYNC and REGOUT). This could possibly be the reason for the Accelerometer not working presently with the PCB but working with the breakout board. We hope that once the new design comes, it will work.
    
    
    
  • Debugging: We were having trouble in reading powers from the board since the old board design had power pins only for programming the board on SWD. So additional pins were added this time. Also, LEDS for 5V and 3.3V power testing were added as well.
    
    

For the next week, we will be testing MPU with the corrected circuit. Our new PCB design will come next week, so we'll get it ready for testing and will try to test at least the very basic tasks. Also, we'll start working on the physical packaging of our PCB on the stick (which involves 3D printing a case).

Week 14:

Date: 13 April 2018
Total hours: 6
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB: We got all the PSSCs checked off by demonstrating the functionality of all the components to Prof. Hadley. Our demonstration involved using our old PCB, where we had to reroute certain traces. However, our new PCB will be delivered on Monday (16 April), from which point on we will be using our new PCB design.
  
• Packaging: We just started with the final packaging of our product. We need to 3D print a box which requires us to make a CAD design of the box. So already have the design from previous weeks, but we need to make final touches and try to 3D print 1 box so that we can see whether it is as per our requirements.

For the next week, we will be soldering and running test on our new PCB design. Additionally, we will be working on the final packaging of our design.

Week 15:

Date: 20 April 2018
Total hours: 10
Description of design efforts:
This week's work was primarily focused on the following tasks:

• PCB: We got our new PCB delivered this week. We soldered the components on it and tested the PCB. Since I was the primary person who designed the PCB, I helped soldering the correct components and helped them identify the correct connections while testing. Also, I helped with figuring out the data being sent and received from different I2C and UART lines by setting up the correct oscilloscope configurations. Finally we were able to get all the components working together on the new PCB.
  Below are the videos that demonstrate us finishing all our PSCCs with the new PCB design.

For the next week, we will be finishing the packaging of the stick.