adding

notebooks/Zhiyuan Yang/README.md

@@ -213,15 +213,145 @@ if (click_flag && diff_time>200){
 ```
 We initialized a counter that counts up every 1 ms (htim2) by configuring the MCU using CubeMX. I think the timer utilized the system clock to count. However, the counter is 16-bit so it can only count up to 65K before rolling over. When it rolls over, we set up the MCU to send an interrupt. We set up a rollover counter to count up when it rolls over. So the counter is actually able to measure 2^32 minutes of time which is more than enough for us. We take the diff time between each clicking motions and only register it when they are 200 ms apart.
 # 2021-11-2  PCB version 1 failed and debug
+Today we had an emergency.
 
-# 2021-11-7 PCB version 1 debugged and testing
+It turns out that our PCB board is shorted between VDD and GND and nothing can be powered when we turned it on.
+![PCB2](./Pictures/PXL_20211103_055900681.jpg)
+We figured out the reason is because the connector holes penetrated the main power line, which is VDD. One of the connector holes is GND.  
+![PCB2](./Pictures/footprint3.jpg)
+We are actively working to fix it and get on with testing. Hope for the best!
+# 2021-11-6 PCB version 1 debugged and testing
+Today we finished testing the MCU chip on our own PCB board and it works!
+
+We deal with the shorting problem by cut out the VDD power line that connects to the GND connector hole, and power the circuit with the VDD and GND pins on the 3.3V voltage regulators instead, which connects to the rest of the circuit.
+
+We soldered on the 64-pin MCU on the board. The process is extremely hard. First, we got scammed by our MCU distributor, who did not send the MCU to us. We had to buy the development board for STM32L152re and take the chip off to solder it on the board. Jeff did most of the soldering process and I helped him solder and test the part. We use heat gun to take off the part and stencil to solder the MCU on the PCB board. We checked on the Microscope to see if all the pins are connected to the board and add solder. When we finally soldered it on and powered up the chip, it was draining 700mA of current which is insane. The impedance of the chip is only 6 ohms but it was in kohms for the chip on the developement board. After exhausting all possibilities, we found out that we soldered on the chip with the wrong orientation. Finally, we got the second board working and successful programmed the chip.
+
+We then confirmed that the shorting is the only issue with our PCB, and Jeff and I went on to design the second verion of PCBs.
+![PCB2](./Pictures/PXL_20211106_040335598.jpg)
 # 2021-11-8 PCB version 2&3 order
+Today, we sent out our second and third version of the PCBs. The footprints are below.
+![PCB2](./Pictures/footprint4.png)
+![PCB2](./Pictures/footprint5.png)
+![PCB2](./Pictures/footprint6.png)  
+The second version is just the one that changed to powerline. Moved it out of the connectors. The third version, we made the PCB more compact to fit on the glove. We found out that the max clock speed by the chip alone is 24Mhz, and we originally had an oscillator on board to boost it up to 32Mhz. However, we figured that 24Mhz would be enough for our project to work so we took out the oscillator.
+
+Jeff observed that our connectors for Gyroscopes board is too big and we could use the same connector as the one with the swd/jtag programmer. So we change them all to 1.27mm swd connectors. Jeff also took out the USB connector since we will only use swd connector. He also took out the wake up button and we could implement software sleep instead. I changed the 2.5V and 3.3V voltage regulators to a newer one TC1264 which is the same packaging but has lower dropout voltage. The old one has 1.2V dropout voltage, and BT module cannot work normally when we were using 3.7V battery.
 # 2021-11-14 accelerometer algorithm update
+When we were waiting for the new PCBs to arrive, we worked on the accelerometer algorithm which is the most important part of the project. To make the accelerometer value more precise. We averaged out 128 acceleration values. We also implemented a calibration procedure and we can take off offsets from the acceleration values.
+```
+temp1[0] = ((data[1]<<8)|data[0]);
+temp1[1] = ((data[3]<<8)|data[2]);
+temp1[2] = ((data[5]<<8)|data[4]);
+a1[0] += temp1[0];
+a1[1] += temp1[1];
+a1[2] += temp1[2];
+if(a_avg_count == 127){
+    for(int i=0; i<3; i++){
+      a1[i] = a1[i] / 128 - offsets[i]; //offset is the calibration offset
+    }
+}
+```
+
+```
+for (int i = 0; i < 3; i++){
+    if (abs(temp1[i]) < temp_threshold){
+      temp1[i] = 0;
+    }
+    if(temp1[i]==0){v_zero_count[i]++;}
+    else{v_zero_count[i]=0;}
+    if(v_zero_count[i]>=v_zero_threshold){
+      v1[i] = 0;
+      v0[i] = 0;
+    }
+}
+```
+```
+if (abs(v1[i]) < 50){
+    v1[i] = 0;
+}
+```
+Since we are integrating accelerations, our velocity values may not always end up zeroing. We have two solutions as described above.
+1. When we counted enough zeros from acceleration values, we zero out the velocity.
+2. When velocity is pretty low in a threshold, we zero it.
 
 # 2021-11-16 bluetooth latency error solved
+Today, we solved a bluetooth latency issue.
+
+We changed to acceleration algorithm to average every 256 values. When we test it on the latency test we found online(https://www.vsynctester.com/testing/mouse.html). We are getting around 20ms of latency, which is lower than our high level requirement. However, when we changed it to 128, we are getting around 15ms of latency, which is better. But when we changed it to 64, the MCU is sending too many reports and overwhelms the bluetooth module. We tried all sorts of things. Read through the datasheet to find that  (SQ,16)  is a command we can use to optimize latency of our chip.
 
+We then changed to a different browser(safari) since chrome might compress several mouse events into 1. We got 4-7 ms of latencies which are very good.
 # 2021-11-21 PCBv3 assembly
+Our new PCBs finally arrived!
+We first performed some connection testing on the board to see if pins should be connected or disconnected. I was in charge of soldering the new gyroscopes boards.
+![PCB2](./Pictures/PXL_20211124_032255655.jpg)
+![PCB2](./Pictures/PXL_20211124_042510222.jpg)
+They are small even with stencil. After I applied the solder paste using a stencil, I checked under the microscope to check if the paste is properly applied. Then I placed the gyroscope on the pads and use heat gun to solder. Finally, I checked under the microscope to see if all the connections to the pads are made. After soldering, I checked the impedance between the pins to see if the electrically properties are correct.
+# 2021-11-26 All functionalities implemented and accelerometer algo update
+This thanksgiving week we all got together and worked on the final functionalities for the project. The code for the project is in code section of the git repo and it is under PCB3_TEST2. We implemented a calibration function.
+```
+if(a1[0]>=220){
+  cx = snprintf(Test, 50, "\r\ncalibration");
+  HAL_UART_Transmit(&huart1,Test,cx,10);
+  HAL_Delay(1000);
+  calibration(a0, a1, v0, v00, offsets, v_zero_count, 100);
+  HAL_Delay(1000);
+  continue;
+}
+```
+There is always a gravity component on the accelerometer. When it is flat on the table, it should read (x,y,z) = (0g,0g,1g). However, if our hand is raised up, the accelerometer is gonna be vertical to the ground at x axis and it will read (1g,0g,0g). In our accelerometer reading of 256 is 1g, so in the calibration code if x acceleration value (a1[0]) is above 220, meaning the hand is raised, then we perform the calibration function.
+
+After discussion, we decided to use the gyroscope on the thumb to act like a basic/Advanced functionalities switch.
 
-# 2021-11-26 All functionalities implemented
+if(active_flag[0] == 1) means there is a click on the thumb gyroscope, we perform the basic functionalities such as cursor movement, and clicking.
+
+if(active_flag[0] == 0) means we are in advanced mode. The gyroscopes click motion would translate to scroll down and release motion would translate to scroll up. When we tilt the accelerometer forward and backward, it would give negative and positive values on x-axis, which will be used for zooming-in/out. When the board is tilted left/right, it would give negative and positive values on the y-axis, which will be used for changing the volume up/down.
+
+We also figured out all the hid reports for all the operations. We looked at the Roving Networks HID section a lot and this website is also very helpful.
+https://wiki.osdev.org/USB_Human_Interface_Devices
+```
+uint8_t vol_up[] = {0xFD, 0x03, 0x03, 0x10, 0x00};
+uint8_t vol_down[] = {0xFD, 0x03, 0x03, 0x20, 0x00};
+uint8_t vol_release[] = {0xFD, 0x03, 0x03, 0x00, 0x00};
+uint8_t zoom_in[] = {0xFD, 0x09, 0x01, 0x01, 0x00, 0x2E, 0x00, 0x00, 0x00, 0x00, 0x00};
+uint8_t zoom_out[] = {0xFD, 0x09, 0x01, 0x01, 0x00, 0x2D, 0x00, 0x00, 0x00, 0x00, 0x00};
+uint8_t ctrl_release[] = {0xFD, 0x09, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+```
+# 2021-11-29 backup code and verifications for demo
+We finished the assembly of the device, which looks super cool now.
+![PCB2](./Pictures/PXL_20211130_164209594.jpg)
+
+Yayati brought a charging unit for the battery and we soldered it on the power pins on the device and we can just plugged in the battery to the charging unit instead. This way the user would not need to unplug the battery to charge it every time. The user just need to charge the charging unit.
+```
+if(abs(a1[1])>=50) {
+  mouse[4] = 5*(a1[1]/abs(a1[1]));
+}
+else {
+  mouse[4] = 0;
+}
+if(abs(a1[0])>=50) {
+    mouse[5] = -5*(a1[0]/abs(a1[0]));
+}
+else {
+    mouse[5] = 0;
+}
+```
+We also prepared a backup version of the code. Since the device only works when our hand is flat, sometimes it is difficult to maneuver it. We only changed the cursor movement part of code and we are only using the acceleration values we get from tilting our hand. Therefore, this mouse will be used like a wireless joystick instead.
+
+```
+if ((mouse[4] > 0 && old_mouseX < 0) || (mouse[4] < 0 && old_mouseX > 0)) {
+  mouse[4] = 0;
+}
+else {
+  old_mouseX = mouse[4];
+}
+if ((mouse[5] > 0 && old_mouseY < 0) || (mouse[5] < 0 && old_mouseY > 0)) {
+    mouse[5] = 0;
+}
+else {
+  old_mouseY = mouse[5];
+}
+```
+Yayti and I also worked on updating the algorithms. We usually got this error that whenever our cursor moves to a direction and when it stops, it will move backwards a bit. These few lines will ensure that our mouse will go in one direction and do not go the opposite direction unless it fully stops.
 
-# 2021-12-2 backup code and verifications for demo
+We finished off the project by performing various verifications that our design documents dictates. Unsurprisingly, they all passed because our project as a whole works. All the verifications can be checked under demo_videos in the git repo.