Project Journal for Stanley So

=============== Week 15: =================

Entry 2: -----------------------------------------------------------------

Date: April 25th
Start Time: 01:36am
Duration: 3.00 hours

• Joshua couldn't get the fingerprint sensor problem fixed, so I'll test compare_1_1 with some old code to make sure it works.
• The old compare_1_1 code (from April 16th) doesn't work. I'll try disconnecting and reconnecting the connections, checking each connection, and if I can't find anything wrong, I don't know.
• Something to keep in mind is that the reset pin is floating. I don't know if it's preferred to be vdd or ground, I'll check that later if reconnecting the thin wire strand doesn't work.
• I reconnected the thin wire strand, wiped off a piece of dust that was on one of the pads, and now it works again. Now I'll go to my real code I was working on earlier today.
• My real code still doesn't work. I'll set a breakpoint right before my add_fingerprint command.
• OMG I figured it out (I'm almost certain). I forgot to delete the user before running add_fingerprint (read the comments in the image).
  
• I came up with an idea to only write to flash memory after the user presses lock, and only read from flash memory when the user unlocks. Other than that, all the files are stored in a 32kB array. This might be doable for us.
• For now, I'll work on fixing missing LCD display texts.
• Fixed that. I also know why our thing is so slow now. We keep repeatedly writing to the LCD display, when we only need to write to it once. I'll write code to only write once now by writing functions for transitioning to every state.
• Finished writing that code and it reduced the input delay drastically. Most of my time was spent writing functions for transitioning into each state and setting the LCD to display the correct text. Here's one of them (there's 7 more of these):
  
• Now I need to enable USB only when the user unlocks the device. I know there's an autogenerated function called MX_USB_DEVICE_Init(), and I'll control click on it to see if there's a deinit function in the same file.
• There is no deinit function, but at the end of the function, there's a USBD_Start function. I'll control click on that to see if there's anything there.
  
• There's a USBD_Stop function. I'll try calling these two functions at the correct places (USBD_Stop on startup and when the user locks the device, and USBD_Start when the user unlocks the device through keypad or fingerprint)
• It works. The USB drive is not present at startup, appears on my computer when I unlock it, and disappears when I lock it.
• Now we have to wait on Abhijay to get here because he knows by far the most about the flash ICs. We should be done with the project after flash IC is complete.
• I put todo statements for where we need to do flash IC stuff (copy from flash into buffer when device is being unlocked, and copy from buffer into flash when device is being locked). Here's one I put after the user enters the correct keypad passcode:
  

Entry 1: -----------------------------------------------------------------

Date: April 24th
Start Time: 11:00pm
Duration: 6.75 hours

• I just got discharged from the hospital. Time to work on senior design lab.
• I need to write the keypad code to convert a matrix value (row and column) into a character on the keypad (0-9, #, and *). To do that, I need to figure out what 0,0 corresponds to, what 0,1 corresponds to, and figure it out from there.
• I wrote code to check if keypad_matrix[0][0] or keypad_matrix[0][1] goes above 10, and if it does, then turn on a debug LED. But it doesn't work (the debug LEDs never light up). I'll check the IOC file to see if I find anything.
• I found nothing. I'll double check my code.
• I don't see anything wrong with my code. I'll go use the debugger to see if it ever goes into the ISR.
• Wait I just realized the keypad was plugged in wrong (with 1 pin offset). I’ll fix that and run my code again.
  
• Code still doesn’t work. I’ll run my old code to see if I’m going insane or not.
• I’m running my old code and now it says failed to start gdb server. I’ll look that up.
• This forum seems to suggest that the ST-Link cannot find the target device. I made the jumper wires more vertical and now I can program it.
• My old code works. I’ll switch back to my newer code and see what is different. This is all the relevant keypad code there is.
  
• The newer code works, but only for [0][0]. I think there’s something fundamentally wrong with my keypad code. I’ll go check the keypad ISR.
• Code for keypad ISR seems fine at first glance. I’ll check the keypad pinout on adafruit.
• Connections seem fine according to the pinout. I’ll run the debugger on my code and step through to make sure everything seems right.
• The keypad_matrix works fine in the debugger? What? I can get keypad_matrix[0][1] over 10 but I cannot get the LED to light up to indicate that. I’ll try just simply toggling that debug LED by itself.
• I can’t turn any of the LEDs on with this simple code? What is going on.
  
• The debugger is jumping between two lines of code not in a loop?
  
• Brandon tried turning on both LEDs, and he can. I’ll try commenting out all the unnecessary initialization code to see if I can turn on the LEDs.
• The debugger is exiting main? I’m giving the code to Brandon to run on his laptop and test.
  
• It works on Brandon’s computer. What.
• I have accepted that I won’t be testing any code and I have to give it to Brandon in order for him to test it.
• Brandon wrote some pseudocode for the state machine that I'm making more precise. He wrote the exact code for the LCD display, but I need to write the exact code for the fingerprint sensor and the keypad.
• A lot of times we have to decode what key each row and column correspond to. So, I wrote a function to do just that.
  
• This is an example of how it's used. It checks every single button to see if it's pressed, sets key to whatever is pressed, and then compares it to the password.
  
• We said in our functional description that have to be able to cancel out of the change fingerprint state. But, that's easier said than done because you cannot interrupt the fingerprint sensor while it's still waiting and hasn't timed out yet. So, we're going to stretch the truth a bit and say that the user selects cancel by waiting.
• Here you can see that if ack_type is not equal to ACK_SUCCESS (caused by bad fingerprint reading or fingerprint timeout), we abort adding a fingerprint, which essentially acts like a cancel.
  
• The lcd display keeps clearing, and the reason for that is because we call clear every single time before we write stuff. I'll change the LCD display to clear only when we change states.
• Ran the code. Some problems are input delay is massive and for some reason selecting # leads to LCD display saying wrong fingerprint instead of wrong password. I'll leave the first issue for later and fix the second issue now.
  
• I read through the code and everything just seems fine except the # and the * got mixed up in the text. I simply just changed the LCD display text to change this.
  
• It now says incorrect password instead of incorrect fingerprint which is good. Now time to figure out why it's instantly going to incorrect password.
• I think I figured out why. Once the key has been pressed for 40 ms, it will register one key press every 4 ms. I think I can fix this by creating an array that flags if the key has been registered already or not.
• I realized that every time I have to check a key, I have to check if it's been pressed for over a certain time and whether it has been registered yet. Then, I have to flag that it has been registered. So, I created a function for this.
  
• I changed the code and it kind of seems like it kind of gives up after the first key press. The input delay is also worse. I think I'll change the keypad ISR to run once every 10 ms instead of once every 1 ms by changing the ARR value from 1 to 19 in the IOC file. I can also change the whole state machine to a switch statement in the main.c file.
• Nevermind it actually all works LOL. It's just that the input delay is massive.
• I made all the changes I did above and it is a lot faster. We still need to add some missing LCD screen displays that we forgot about though. I'll do that now. (We forgot to make the LCD screen display "Enter Password" and "Enter Fingerprint" and "Unlocked")
• I did the above, but I also forgot to change the debouncing delays in my code (since I made the timer 10x slower, I need to make the debouncing delays 10x less in code). I'll do that now.
• For some reason entering the keypad passcode doesn't work anymore. It only inputs 3 values instead of 4. I'll look into it by inspecting the code. Also, my keypad code is no longer the limiting factor in speed. Although I changed the debouncing to be 10x less, the amount of time you have to hold definitely did not decrease by 10x.
• I ran the debugger and I figured out the problem. Count starts at 0 and increments up to 4. But since this increment is before the array index, we're trying to read at array index 4. But the highest index is 3. I'll just move count++ to after the array checking code to fix this.
  
• it seems to work now, except for the fact that the fingerprint sensor is not responding a lot of the time. It's supposed to make a beeping sound when it turns on. I think this might have to do with our system being so laggy that the 1s transmit timeout is too short. I'll change that timeout to 100s to see what happens.
• that didn't work.
• tested changing keypad password, which worked.
• we need to get the fingerprint sensor working and make it faster when I come back.

=============== Week 14: =================

Entry 5: -----------------------------------------------------------------

Date: April 18th
Start Time: 11:58pm
Duration: 0.50 hours

• Moving senior design journal to website and adding pictures

Entry 4: -----------------------------------------------------------------

Date: April 16th
Start Time: 12:50pm
Duration: 3.00 hours

• I need to get the fingerprint sensor code working for our PCB. I’ll look in main.c and fingerprint_sensor.c and the corresponding header files.
• I think that all the existing code will work on the PCB. Just needed to change huart5 to huart4, but that was already done. I’ll write the code in the main function now. I’ll call these functions in this order:
  1. delete_specified_user for user 0
  2. add_fingerprint (3 times) for user 0
  3. compare_1_1 against user 0
• Wrote the testing code.
  
• Found the heat gun. I’ll watch over Abhijay to make sure that everything goes smoothly with shrinking the heat shrink.
• He succeeded with one connector, so I think he should be fine. I’ll go write code that should work with the keypad now.
• I think I just need to change the pins that the keypad works with. I’ll do that now.
• I tried running my fingerprint sensor code with the fingerprint sensor plugged in but nothing is happening. I’ll try to turn on an LED and see if I can do that.
• I can do that. I’ll use an oscilloscope probe to see if I’m sending any UART data.
• Yes, I am sending UART data. I’ll check baud rate now.
  
• Baud rate seems fine in the IOC file. I’ll check the pinout of the connector, because everything else seems to be working.
• I found out that the pinout is wrong. It’s flipped. So, we have to crimp the 6th pin.
• I crimped the 6th pin of the big connector and Brandon crimped the 6th pin of the small connector. I then stripped the wires, so Brandon could solder them together.
• Fingerprint sensor works now. I’ll work on keypad now.
• The keypad is not working. I used the debugger to try and see if the ISR was getting triggered, and it is not getting triggered. I’ll look it up.
• I think I remember what I am missing. I forgot to start the timer. I will do that with HAL_TIM_Base_Start_IT(&htim7);.
• The LED I’m using to test is now just blinking randomly. I guess that’s an improvement.
• I found out that the pinout changed from what Abhijay gave me. So I’ll change that in main.c now.
• Keypad works now. The LED blinks when I press the keypad. Here is the keypad code for reference.
  

Entry 3: -----------------------------------------------------------------

Date: April 14th
Start Time: 03:49pm
Duration: 3.50 hours

• I’m going to try to crimp the small connectors now. Brandon had success crimping with the thin blue 30awg wire, so I’ll try that.
• Crimping is so easy with the new wire! I put the crimp terminal inside the 1.0mm slot, placed the wire inside, and crimped it with a lot of force.
  
• I got the wire inside the housing using some tweezers. The tiny spring side should face the holes when you put it in. I tried connecting it and tugging on the wire, and it didn't come out. (the 4th wire is mine)
  
• I will try creating the real fingerprint sensor connector now. I think I’m confident enough with how smoothly that went.
• I think I didn’t shave enough crimp terminal off, and the crimp terminal bent the housing a lot. I then tried pulling the crimp terminal out by squashing the spring, but ended up breaking the wire in the process. I think next time I have to make sure that my crimp terminal is shaved super well before putting it inside the housing.
  
• I will start over with a different housing. I’ll try and salvage that housing if I need to.
• Brandon told me to use the flat part of the crimpers to squish the housing a bit and make it thinner. That makes it so I can put it inside the housing more.
• Finished making the connector. Now time to solder it to the other wire.
  
• Stripped the wires and twirled the wires together and put heat shrink on the wire. Now time to solder it together.
• Soldered it together by putting the iron on the bottom of the wires and putting the solder on the top of the wires. Now time to put the heat shrink over and use a heat gun to heat it up.
  
• I cannot find a heat gun and all the TAs are gone. I’ll just solder all the wires and do the heat gun stuff later then.
• Soldered all the fingerprint sensor wires.
  

Entry 2: -----------------------------------------------------------------

Date: April 13th
Start Time: 06:44pm
Duration: 1.50 hours

• Making the end of the connector connected to the LCD display using the whole process I described in previous journals
• Finished.
  

Entry 1: -----------------------------------------------------------------

Date: April 12th
Start Time: 04:39pm
Duration: 3.50 hours

• Completed Ethical and Environmental Analysis report

=============== Week 13: =================

Entry 4: -----------------------------------------------------------------

Date: April 12th
Start Time: 01:39am
Duration: 0.75 hours

• Moving all of week 13’s journals to the website and adding pictures

Entry 3: -----------------------------------------------------------------

Date: April 9th
Start Time: 12:30pm
Duration: 2.00 hours

• Talked to Joshua about new prototype. I told him that
• We need to make the holes on the top of our case bigger to fit our new connectors
• We need to make the top of the case bigger for all our components to fit on top.
• We need to find a way to mount the fingerprint sensor board inside of the case.
• I got all the parts for Joshua to measure. I also laid out what I think the top of the case should look like.
  
• I think if we have enough room after Joshua makes the case bigger, we can make a hole through the bottom of the case and screw into the fingerprint sensor.
• For now, we have to wait for Joshua to make the case bigger first.
• I’ll keep trying to make connectors now.
• I put the crimp terminal inside of the helping hands, placed the wire inside, crimped it with my other hand with the 1.4mm setting, and it worked!
  
• Nevermind it fell out. Bruh. Maybe I try using the 1.0mm option on the crimper.
• The 1.0mm option crimped the wire too hard again. Maybe I’m using too much force.
• Brandon used a lot of force and 1.0mm crimp settings and he had success with it. Maybe the 1.0mm setting is good, but maybe don’t go too crazy on it.
• Used less force and I think I got a good crimp. I’ll try to put this into the housing now.
  
• I cannot get the wire into the housing. Brandon pointed out that the insulation might be too thick, so when we put the wire inside of the housing it bends it a bit. We might have to crimp around just the stripped wire and not the insulation. I’ll try that next time.
  

Entry 2: -----------------------------------------------------------------

Date: April 8th
Start Time: 03:05pm
Duration: 3.75 hours

• I will try again to make connectors. I need to start by stripping the wire again.
• Stripped the wire. Now I will cut around a new crimp terminal to separate it from the reel.
• Cut around the crimp terminal. I need to make sure that I don’t cut off / flatten the tiny spring that will hold it inside of the housing. Now I need to cut off the wire so then the stripped end length matches the middle part of the crimp terminal.
• Did that. Now time to put the middle part of the crimp terminal inside of the crimper, put the exposed end inside the middle part, and press down on the crimper handles.
• Crimped the middle part. Now time to crimp the insulation part by doing the same thing.
• I got the crimp terminal out of the crimper by using a tweezer to stick into the crimper and pry it out.
• Crimped the insulation part. Now time to try and put it into the housing again (with the tiny spring facing the same way as the hole).
• Got the wire in by using an oscilloscope probe to poke it in. now time to connect it to some header pins to see if the wire falls out.
  
• It doesn’t fall out! Now time to cut the wire too long (because it’s much easier to make a wire shorter rather than longer) and crimp the 5 remaining terminals.
  
• I crimped another wire into the housing, but the most time-consuming part by far was trying to strip the wires with the wire cutters. I’ll go look to see if there are any 28 AWG wire strippers.
• Found one in the cabinets. I will keep crimping connectors.
• Checking the PCB for the fingerprint sensor shows that I only need to crimp 5 wires into this housing instead of 6 since the 6th pin is not connected.
  
• Taught Brandon how to crimp wires.
• Made one end of the fingerprint sensor connector. Now time to make the other end. I’ll practice crimping with a wire I don’t care about before trying to use the actual connector wire, since the other end connector is different.
  
• The crimp terminals on the other end are a lot smaller, so I have to find a smaller crimper. I’ll look in the cabinets to see if I can find a smaller crimper.
• I cannot find a smaller crimper. I’ll look up how to crimp JST SH connectors and see how they do it on YouTube.
• I watched this video and the guy seems to use crimpers that don’t actually hold the crimp terminal in place, but it still gets the job done. I’ll try with the crimpers that we have then.
• They also use tweezers to slightly wrap the crimp terminal around the wire before they crimp which helps them.
• They also keep the reel on the crimp terminal until after they crimp it which helps them position it inside the crimper better.
• Abhijay lost a bunch of our TVS diodes so we have to buy more. I’ll buy them directly off of DigiKey.
• Bought them.
  
• I broke the wire off of the crimp terminal. I think I crimped it with too small settings. I’ll crimp it with the same settings I used for the other crimp terminal next time (1.4mm).
• Next time I also have to look up which way you put in the crimp terminal because the crimp terminal is different for the JST connectors.

Entry 1: -----------------------------------------------------------------

Date: April 7th
Start Time: 04:34pm
Duration: 3.25 hours

• I’m going to spend the first part of lab cleaning because what is this
  
• Cleaned everything I could. Now time to open my DigiKey package and start making male connectors.
  
• Scanned the packing slip and sent it to engrpslip@purdue.edu
• I need to figure out how to crimp wires again. I’ll watch this video to refresh my memory.
• I learned that:
  1. I need to strip the wires, so then the exposed wire is the same length as the middle part of the crimp terminal
     
  2. Put the middle part in the crimper, place the wire inside the crimp terminal, and then crimp by pressing down on the handle.
  3. Then use the crimper to crimp the insulation part of the crimp terminal
  4. Then put the crimp terminal into the housing, and it should make a click when inserted
• I will get some 28 AWG wire and strip it now by cutting the outside plastic with a wire stripper (or scissors), and then pulling it out with my fingernails.
• I cannot get the crimp terminals off the reel by just pulling it with my fingers. I’ll look up how to do it.
• I found this video which tells me to use flush cutters to get the crimp terminals off by cutting around it.
• Found flush cutters in one of the cabinets.
• I realized that the crimp terminals in the video are different. Our crimp terminals have essential components on top of the reel, while the video’s doesn’t. There’s a little thing sticking out of the bottom of the reel. I tried cutting that off, but I still can’t get it off the reel.
• I tried cutting around the crimp terminal (and leaving the reel on) but it doesn’t fit inside of the housing. I think I have to actually remove the crimp terminal from the reel properly.
• By cutting more flushly around the reel, I can actually get it to fit inside the housing. I think I’ll do that.
• Stripped the wire by stripping too much, and then cutting off the wire until the exposed end is the correct length.
• I messed up the crimping because I accidentally put the end inside the crimp terminal, and it got squashed. I’ll need to find a thinner crimper that only holds onto the middle terminal.
  
• I found thinner crimpers in the cabinet. I’ll try crimping again with a different crimp terminal.
• Crimped the wire. Now time to put it inside the housing.
  
• I don’t know which way you’re supposed to put in the crimp terminal into the housing. I’ll look up how to put it in (and how to push it in more).
• I found this video which says to use a screwdriver to push in the wire more. I used an oscilloscope pin, and guessed that the part that sticks up on the crimp terminal goes on the same side as the exposed holes. I got it to push in all the way (I think). I tried connecting a header into the connector, but then the wire got pushed out again. I’ll try putting in the wire the other way and see if it locks in place.
• I can’t push it in nearly as much the other way, so I’ll assume that I had it right the first time.
• By pushing the crimp terminal too many times, I accidentally broke the wire off the crimp terminal. I’ll get the crimp terminal out with a screwdriver and try another crimp terminal. I’ll look it up and try to find the exact connector I have before trying again.
• I found this video, and you’re supposed to put in the crimp terminal the other way (with the part that sicks up facing away from the holes). There is a tinier spring that is supposed to connect into the hole and prevent the connector from coming loose.
  

=============== Week 12: =================

Entry 5: -----------------------------------------------------------------

Date: April 4th
Start Time: 10:41pm
Duration: 1.00 hours

• Moving all week 12 journals to website and adding pictures

Entry 4: -----------------------------------------------------------------

Date: April 2nd
Start Time: 12:30pm
Duration: 2.00 hours

• We need to continue soldering. We will start with the microcontroller. I will melt solder onto one corner pad and Abhijay will slide the microcontroller in place. Then Brandon will do the drag soldering.
• We tested the electrical connections of the microcontroller and we have one bridge. We are using a desoldering braid to try and remove solder.
• It didn’t work, so we will go wash the board with some water to remove some of the burnt flux to see better.
• I’m helping Joshua with the mechanical design by giving him the specific dimensions I want for each of the holes for our components. We got those dimensions by measuring with a caliper and seeing what looked fine.
• After looking at the bridge with the microscope, we think it’s super high up on the pins. We tried drag soldering it again without any solder, and after testing it electrically again (all 64 small pins), it works!
• Talked with Joshua about the sizing of some components. It helps that we have a working personal project (my diabolo lights) for reference to measure. We measured the diameter of the pegs for the diabolo lights, and measured the diameter of the hole for the diabolo light PCB. The diameter of the pegs was 2mm, and the diameter of the hole was 2.7mm. So, we are going to give 0.7mm of leeway to our project. Since in our project, the holes are 3.2mm, we will make the pegs 2.5mm diameter.
• We also talked about the distance the USB can be inside the case. The case is 2mm thick, and the housing of the USB connector is 3mm away from the female case. So, we can put the PCB 0.5mm inside of the case, and the USB should still be able to plug in.
• Soldered the programming headers. After uploading code to alternate two LEDs, we can see that we can program the microcontroller now.
  

Entry 3: -----------------------------------------------------------------

Date: April 1st
Start Time: 11:15pm
Duration: 1.00 hours

• We found out that the senior design course staff don’t have some of our resistor / capacitor values in stock, so I’m going to go order them now. I’ll probably order them with my own money because I need them ASAP.
• I’m on the DigiKey ceramic capacitor section with the filters Package / Case = 0805, exclude marketplace, and capacitance = whatever I need.
• I’m also doing the same on the DigiKey chip resistor section.
• Filled out all the parts that we haven’t soldered yet that are on our bill of materials.
  
• Ordered all the parts directly through DigiKey.

Entry 2: -----------------------------------------------------------------

Date: April 1st
Start Time: 02:57pm
Duration: 4.00 hours

• I forgot to fill out the component checkout form for the 0805 LEDs, so I’ll do that now. In order to test power, I guess we can just use an oscilloscope.
• Turned on the soldering iron.
• We are going to start by soldering the power network. We placed the USB (our power source) under the board in a soldering position.
  
• Soldered the USB to the board by adding flux, putting solder on the soldering iron, putting the soldering iron onto the pin and the pad, adding more solder if necessary, and then lifting the soldering iron off of the pad. Now time to clean off flux.
  
• I need to find out how to get capacitors out of a tape and reel.
• Abhijay pointed out that the USB was soldered on a bit crooked, so I’ll desolder it with a desoldering gun I found at one of the shared soldering stations and fix it.
  
• Got the capacitor off the tape. You rip off the top, and then poke at the tape until you create a hole that you can stick a sharp thing into and peel.
• The desoldering gun is not working. I’ll look up how to use a desoldering gun.
• I looked it up, and found this video. He cleans out the desoldering gun by sticking a stick into it. I tried to stick a stick into my gun, but no matter what I do, I cannot get it through. I think the desoldering gun is too jammed for me to use.
• Abhijay and I tried heating up the through holes with two soldering irons simultaneously, but we can’t get all the solder to melt. I think it will be easier to just start with a new board.
• We soldered the USB on a new board (and held it up using tape) and now it looks better.
  
• We soldered our LDO by using tape to hold it in place. But the tape melted, so maybe we switch to some other tape, or just don’t use tape at all.
• Watched this video to figure out how to solder surface mount components. You basically melt solder onto one of the pads, keep the soldering iron on the pad and use some tweezers to push the component into the pad, and then solder the other pad.
• Soldered the decoupling capacitors for our LDO. Now we need to find a male to male USB cable to test our power network.
• We cannot find one. We’ll go to the ECE shop to find it.
• We tried using a USB-A to USB-C cable, but reading voltage with the multimeter reads like 0.7V when it’s supposed to be like 5V.
• We cannot find a male to male USB cable, so we are just going to use our USB A cable to wires and use a 5V power supply to test our power.
• Nope, still same result with the multimeter. We’ll try soldering our heartbeat LEDs to see if that works.
• The 5V heartbeat LED works! Time to solder the 3.3V LED now.
  
• 3.3V LED works! Time to solder the microcontroller circuitry now.
  
• We found out that the oscillator is very not friendly to solder because all the pads are below it. We talked to a TA, and he said that we can try to solder it if we get a brand-new board, apply solder paste, and use the hot plate. Basically, we have to start over and solder the oscillator first.
• Applied solder paste to a new board by taking a stick and putting it onto the pads.
• The board has cooled down now. We need to test for shorts.
• The crystal has no shorts! Time to re-solder everything.
  
• We resoldered the 5V and 3.3V heartbeat LEDs. I found that pressing the soldering iron on the pad (and not hovering it) lets Abhijay go in with the tweezers much more easily.
• We are soldering one component at a time and then testing connections.
• This is how far we got. We soldered the power network, the reset button, the debug LEDs, and the heartbeat LEDs. We need to solder all the other components tomorrow.
  

Entry 1: -----------------------------------------------------------------

Date: March 30th
Start Time: 05:59pm
Duration: 2.75 hours

• I just realized that I bought the wrong connector to connect to off-board components. It’s fine for the PCB, just not the off-board stuff.
  
• I need to:
  1. Find the correct connector for the regular header pins
  2. Print out the PSDR checklist
• Looking it up, there are two main options I see: solder wires directly onto the headers, or use a female box connector. I’ll look up female connectors on DigiKey.
• I found this page on DigiKey, but all the female sockets have a wire at the end of them that you’re supposed to use to solder into a PCB.
  
• I found this https://www.amazon.com/CHENBO-Connector-Housing-Assortment-Terminal/dp/B077X8XV2J which looks like what I need (you crimp the wires yourself). I’ll see if I can find only the parts I need on DigiKey though.
  
• I searched “Male Female Crimp Pin Connector” on DigiKey and I found the section for rectangular connector housings which looks more like what I want.
• Our headers are 2.54mm pitch (breadboard-friendly distance), so I applied the DigiKey filter for that.
• We need an 8 pin housing for the keypad, a 6 pin housing for the fingerprint sensor, and a 10 pin housing for the LCD display.
• I found this part for the 8 pin housing. Now time to find out what crimp terminals I need.
  
• The datasheet lists a bunch of different crimp terminals. They all list as KK 254 crimp terminals. I’ll look that up on DigiKey.
• I found this part through that search. I noticed that the series includes KK 254. I’ll look up with the DigiKey filter for better results. (look at the pictures, idk how to describe it)
  
• Found this part. I think I’ll use this, since it looks more like what I had in mind.
  
• I will look up for 6 pin housing now.
• Found this housing for 6 pin. It is the same series of connector, so I think it can be used with the same crimp terminal. Time to look up 10 pin housings now.
• I found this housing for 10 pin. Once again, it is the same series, so I think it can be used with the same crimp terminal.
• The JST SH series works with 28-32 AWG wire. 28 and 30 AWG wire should be fine with both the JST and the Molex connectors then.
  
• Now I need to fill out the procurement purchase request form for these new parts.
• Actually, I’ll first look at the shared solder station to see if I can find 28 or 30 AWG wire.
• I found both 28 and 30 AWG wire. I’ll start the purchase form now.
• I put a quantity of 3 for each housing because we only need 1 of each, and I’m sticking by my 2 extra thing.
• I need 9+7+5=21 crimp terminals (since each device has 1 pin that is unconnected). I’ll buy 30 so we have some extras.
• Filled out all the parts. Time to calculate shipping by adding all of the parts to my cart on DigiKey.
• Did that (shipping was $6.99). I have to send out the purchase request email now.
  
• Sent out the purchase request email. Now I have to fill out the PSDR checklist, print it out, and put it on our lab bench.
• Finished the PSDR checklist. Now I have to figure out how to print.
• It says to download mobility print and print like normal, but it is not working on my Windows computer. The printer doesn’t show up when I go try and print from Microsoft Word. I’ll see if it works on my phone.
• It works on my phone. I’ll print from there.
• Walked to WALC to print out the sheet. Now I will walk around the lab to find tape.
• Found tape in one of the cabinets and taped the sheet to our bench.
  

=============== Week 11: =================

Entry 2: -----------------------------------------------------------------

Date: March 28th
Start Time: 10:05pm
Duration: 1.50 hours

• Moving all week 10-11 journals to website and adding pictures.

Entry 1: -----------------------------------------------------------------

Date: March 26th
Start Time: 12:30pm
Duration: 2.25 hours

• Went to Phil Walter’s meeting. Since we don’t have our parts yet, there’s only a limited amount of things we can do. I think I’m going to go do some soldering practice today.
• I’m going to look up some drag soldering videos from Brightspace.
• I turned on the soldering iron so then it will be hot by the time I use it.
• Watching this video. I don’t know what IPA, sponge swab, and kimwipes are (the video uses these to clean the board before drag soldering), so I’ll look it up and see if we have any.
• I found this slide on the lecture slides which gives me a step-by-step guide on how to solder surface mount ICs (without cleaning first). I’ll look to see if the slides tell me how to clean the board first.
  
• I couldn’t find anything, so I’ll watch this video about flux usage that was linked in the lecture slides.
• The last part of the video says that you can use isopropyl alcohol and a cotton swab to clean off flux. I’ll go try to look for those.
• I can find cotton swabs, but not isopropyl alcohol. I can find a ton of water bottles, though. I looked up whether you can use water to clean off flux, and I think you can.
• I found the specific flux pen that we have (Kester 2331-ZX flux pen). I’ll look up if it’s water-soluble.
• I think it’s water-soluble. Ok, time to follow the steps in the lecture slides.
• I am trying to get solder onto the corner pins and I cannot, LOL. I will watch the drag soldering video to see how he does it.
• I am just going to try to be aggressive with my solder application and see what happens.
• Being aggressive with solder did not work. I tried adding flux to the pins of the microcontroller, and that actually worked!
• I added too much solder and successfully shorted all the pins, LOL.
  
• Watching the drag soldering video, the guy just puts the soldering iron on the end of the pin and the solder kind of just separates. I’ll try that.
• It didn't work. I think there is just too much solder on the pins. I’ll look up how to desolder.
• I just realized that you are supposed to use a flat tip soldering iron. I’ll try switching to that after I desolder.
• Got a lot of the solder out with the desoldering pump, and I placed the soldering iron sideways. All the pins are still shorted, though.
• I’m trying to melt the solder, use the desoldering pump, but it’s not working anymore. Let me try adding more flux.
• Nope, didn’t work. I realized that the drag soldering video doesn’t press the soldering iron against the side of the pins, instead pressing the soldering iron on the tip of the pins and the PCB. I’ll try that.
• By pressing the soldering iron on the tip of the pins, and repeatedly only pushing the solder one way, I freed up 3 of the pins on the corner. Maybe if I keep pushing this direction, I can push more solder off and un-short more pins.
• I ended up re-shorting all the pins when I tried it again. I also tried going really aggressive with the soldering iron, putting the soldering iron on the chip for way too long (like 60 seconds) and using the desoldering pump repeatedly, but I cannot get the solder off. I also ended up burning stuff. I’ll look up how to get a lot of solder off a surface mount IC on the internet.
  
• I found this video and this guy uses a ton more flux than I do. Maybe the flux pen is dried out or something.
• I looked it up and found this forum where apparently flux pens are bad, and you need to push down with the flux pen in order to get flux flowing. I barely see any liquid coming out of the flux pen. I’ll look around lab to see if I can find any other flux sources.
• I can only find flux pens in lab. I found a flux pen from a shared soldering station that actually feels like there is liquid in it when you shake it. I’ll try using that.
• I used that flux pen, and there is so much more liquid that comes out. However, I still cannot get rid of the shorts. I will ask a TA what to do next time I come to lab.
• I’ll just clean off the flux for now and call it for today.
• Cleaned off the flux by squirting some water onto the board and using a cotton swab to clean it up. Now the board looks way less burnt, which is good.
  

=============== Week 10: =================

Entry 4: -----------------------------------------------------------------

Date: March 18th
Start Time: 03:32pm
Duration: 3.75 hours

• Time to lock in again. I need to:
  1. Order the parts
  2. Order the PCB
• To do #1, I’ll export the new Bill of Materials and see if my components and quantity match. I’ll also add:
  • the parts we used for prototyping, since it doesn’t hurt to get an extra just in case.
  • the connector housings we need
• The PCB parts look good. Time to add the stuff I listed above to the list.
• I think I should buy the Waveshare fingerprint sensor from Amazon rather than Waveshare (even though it’s more expensive on Amazon) because it’s a more commonly used vendor than Waveshare and less likely to be banned. It’s also on this list of vendors that I’m referring to.
• I need to fill out a phone number and an email for Amazon. I can’t find it anywhere on the website, so I’ll look it up.
• All the Google search results just redirect back to this page which doesn’t have any contact info on it.
• I found this https://www.elliott.org/company-contacts/amazon/ which actually lists phone numbers and emails but is not the Amazon website. I’ll just use this, I guess. I don’t think this is that important.
• Finished putting down the prototyping parts. Now time to put the connector housings according to this datasheet (look at the housings with protrusions)
  
• I’m not sure if the housing is all we need. I’ll look up a tutorial on how to crimp JST SH connectors to see if that’s all we need.
• Found this tutorial which goes through the crimping process, but I want to see the whole process (putting it into the connector). I’ll look that up.
• I found this video which shows me something interesting. You can use the JST connector to connect to regular header pins as well if you have the right wire socket. (I think it’s called that?) The one on the bottom can connect to regular header pins, but the one on the top can’t.
  
• Looking up the wire socket in the JST datasheet brings me to this part on DigiKey. The image on DigiKey (and the datasheet) seems to match the right wire socket based on the picture above.
  
• So I guess for each connector header we buy, we have to buy two connector housings, one to connect to the PCB and one to connect to the off-board component. We also need to buy one wire socket for each pin on each connector housing.
• We need 38 wire sockets because we have 2 7 pin connector housings, 1 6 pin connector housing, and 2 9 pin connector housings. 2*7 + 1*6 + 2*9 = 38. We only need 1 6 pin connector housing because the fingerprint sensor comes with wires coming out of it already.
  INSERT PICTURE
• Finished putting down all the parts. Now time to think about how many extras we need of each part.
  
• I think for the prototyping parts, I’m going to leave them at a quantity of 1, since we already have replacement parts in lab (and they’re kind of expensive). Everything else is going to have at least 1 extra part.
• I’ll calculate shipping cost at the end, after I consider all the extras.
• I think I’m going to get at least 2 extra for all the cheap components.
• For the JST wire sockets, I think I’m going to get 50 (12 extra) so then I get the next discounted price.
  
• The flash IC and the microcontroller are not cheap. The flash IC is $4.30 each and the microcontroller is $14.41 each. I think I can afford to get two extra of both of these, since we have a $440 budget and I don’t think we spent any money yet.
• Finished adding extra components. Now time to calculate shipping costs by adding all the components into a cart and setting the shipping address to the BHEE building.
  
• DigiKey also charges a tariff for some reason. I looked up if tariff is part of shipping and handling, and according to this website, tariffs are taxes, so I guess they’re not shipping and handling, and I won’t include that cost on the procurement ordering form. Anyway, the shipping and handling cost is $6.99 for 3-day delivery (and we have 5 days between the procurement office opening again and Monday, so I think that’s fine).
• I just realized that the fingerprint sensor says that it arrives between April 8th – 17th from Amazon. That’s not great, but we have our Waveshare A fingerprint sensor to work with, so I think it is actually okay.
• That might actually mean that we have to create another connector for the A fingerprint sensor then, assuming the D fingerprint sensor arrives last minute. (the pinout is slightly different for the D fingerprint sensor). That would mean buying two more 6 pin connector housings, and 12 more wire sockets. I’ll do that. It’s not a big deal since they’re so cheap.
• Changed the 6 pin JST SH housing amount to 5 (1 for D fingerprint sensor connection, 2 for A fingerprint sensor connection, 2 extra) and the JST wire socket amount to 60 (2 7 pin housings, 3 6 pin housings, 2 9 pin housings, and 10 extra).
• I think I’m done with the ordering forms now. The total amount including taxes and other fees is $190.75, which leaves us with about $250 to spare.
  
• Now time to send an email to the procurement office. I’ll read the brightspace stuff to see how I’m supposed to do this.
• Some key takeaways:
  • Put “ECE Senior Design” in the subject
  • Submit packing slip after you receive your package
• Sent the email for the parts. Now time to order the PCB.
• I have to export the Gerber file from KiCad. I’ve never done this before, so I’ll look up a tutorial on how to export a Gerber file from KiCad.
• I found this tutorial which tells me how to generate the Gerber files, but not zip them and order from JLCPCB. I’ll look up how to do that.
• Found this tutorial which is pretty much exactly what I want. I’ll follow this tutorial.
• Following the tutorial:
  1. Select file -> fabrication outputs -> Gerber
  2. Copy all the options that the video selects and press plot
  3. Select file -> fabrication outputs -> Drill Files
  4. Copy all the options that the video selects and press generate drill file
  5. Press Generate Map File
  6. Compress the folder to a .zip file
  7. Upload the PCB to JLCPCB
• I’ve ordered PCBs from JLCPCB before, so I don’t think I need a tutorial from here. I selected untented vias and lead-free HASL surface finish, and kept all the other options the same.
• In KiCad, checking File -> Board Setup -> Physical Stackup gives me a PCB thickness of 1.6mm, so I’m going to select 1.6mm board thickness on JLCPCB.
• Order placed. Very nice. I’m so glad to be done with everything. I’ll go tell the TAs that we ended up ordering the board ourselves.
  
• Time to send an email to the TAs saying that we ended up ordering the board ourselves, put the Gerber file on the website, and submit the JLCPCB invoice to Brightspace.

Entry 3: -----------------------------------------------------------------

Date: March 18th
Start Time: 11:27am
Duration: 1.00 hours

• Updates since last journal entry:
  • I emailed the TAs asking them what we should do regarding our ESD protection diode. Brandon and I have not received responses to our emails, so I’m assuming that the TAs are all on spring break, and they’re not going to get back to us soon.
  • We decided that we are just going to order the PCB ourselves with our own money. We can’t really afford to wait any longer to order it, and it shouldn’t be that expensive (like $25 including shipping?)
  • We decided to switch to the new ESD protection diode.
• I’m going to finish ordering the parts through the procurement office today. I was concerned that the procurement office might be closed, so I googled it, and came across this website which says that the procurement office is open Monday-Friday, but closed on weekends and university holidays. Let me look up if spring break is a university holiday.
• I found this website which doesn’t list spring break as a holiday. I think we’re good to order through the procurement office then.
• I think that we might need to order extra keypad, fingerprint sensors, and LCD displays just in case. I’m pretty sure we have extra keypads in lab, so I might not need to order that. I’ll ask my groupmates what they think.
• Nobody got back to me, so I’ll put them on the procurement office purchase request forms, calculate the cost, and get back to my teammates.
• I'm going to reroute the PCB before I continue filling out parts because I need an up-to-date bill of materials to fill out the part quantity.
• I need to update the schematic first with the correct wiring.
• Updated the schematic with the new ESD protection diode. Now time to route.
  
• Rerouted everything. (pictures taken without ground fill because you can’t see anything with the ground fill)
  
• After moving some silkscreen around, everything passes DRC. Time to push to GitHub. I will have to come back, order parts, and order the PCB after lunch.

Entry 2: -----------------------------------------------------------------

Date: March 16th
Start Time: 07:00pm
Duration: 2.00 hours

• We decided not to change USB lines at all, since if we make them thicker, we can’t connect them to the microcontroller.
• We need to order parts for our PCB, so I’m doing that right now.
• I generated a Bill of Materials from KiCad by going into the PCB file, and clicking file -> fabrication outputs -> Bill of Materials.
• I tried to open the file with Excel, but the formatting was all messed up. I looked at the file in notepad and saw that all the delimiters were semicolons instead of commas. I’ll look up how to solve this.
• I found this forum which tells me that I have to create a new line at the top of the CSV file and put “sep=;” (without quotes) on it.
• After downloading the procurement process form, it looks like you have to fill out a separate sheet for each vendor. I’ll first start with DigiKey because most of our parts are from there.
• I’m not sure if we have 0805 LEDs in stock, so I emailed Shivam and Xiang asking about it.
• I accidentally deleted the component ordering form, so I had to find out how to restore it. I found this https://support.microsoft.com/en-us/office/recover-an-earlier-version-of-a-word-file-439d91d7-fe33-4edf-aa94-4b631c7ac380 which says to go to file -> info -> manage documents -> recover unsaved documents.
• I have to restart from the first component, but that’s not too bad.
• I just realized that we should probably get extra parts in case we damage something. I’ll put the minimum quantity for now, calculate the costs, then calculate the costs with 1 extra part for each, and then calculate the costs for 2 extra parts for each. We can decide how many extra parts we want based on cost.
• I found out that the ESD diode that was picked out was not actually designed for ESD protection, according to the datasheet. I’ll go look for one that is and matches the same footprint and pinout.
  
• By searching TVS diodes on DigiKey with the supplier device package filter set to SOT-23-3, I can find a bunch of TVS diodes with the same package, but none with the same pinout as the one that we’re currently using. It might be a good idea to just change the PCB a bit to match.
• I think we should just choose a hand-solderable TVS diode. We probably have to change the schematic, update the PCB, re-upload to the website, and re-email the TAs. I’m judging whether the component is hand-solderable by looking at the datasheet, seeing if it’s smaller than an 0805 resistor (2mm x 1.25mm), and if it is, then I’m deeming it not hand-solderable.
• There’s this parameter for all the ESD diodes called reverse standoff voltage that I don’t understand. I’ll look it up.
• I found this article that tells me that reverse standoff voltage is the voltage that you can operate at without the diode conducting current.
• I also came across this forum that says that I can probably choose a TVS diode with reverse standoff voltage of 3.3V, but if I want to be safe, choose one that has a reverse standoff voltage a bit higher (like 5V).
• I’m going to go back to DigiKey and search with a filter with reverse standoff voltage between 3.3V and 5V.
• I found this part which has a reverse standoff voltage of 5V, and is in an SOT-23 package which is easily hand-solderable. It might actually work with our current PCB if all the dimensions are the same as the part we picked originally.
• Nevermind, the dimensions are very slightly different. The distance between the two pins on the same side (labeled G in the first picture) is 1.83mm on the TVS diode, and 1.9mm on the zener diode. I think we should just change the schematic, footprint, and PCB layout to the TVS diode.
  
• Actually, I think a better idea might be to email the TAs first, explain to them that we copied the ESD protection diode from the slides, didn’t realize that it wasn’t made for ESD protection, and ask them if they think it’s fine or not.
• I asked my groupmates in discord what they think we should do.

Entry 1: -----------------------------------------------------------------

Date: March 15th
Start Time: 07:00pm
Duration: 0.50 hours

• I don't understand Setsuna's USB comment. Increasing the USB trace thickness will increase the capacitance of the trace (think parallel plate capacitor). I'm going to do some research online and then ask her about it.
• The Google AI agrees with Setsuna, but I checked the sources it cites, and I cannot find anything that agrees with the AI. I'm using Ctrl + f for "width" and I find nothing useful. https://www.protoexpress.com/blog/best-layout-tips-for-high-speed-and-high-current-pcb-traces/#:~:text=Maintain%203W%20to%205W%20spacing,increase%20trace%20current%20carrying%20capacity https://electronics.stackexchange.com/questions/604440/pcb-tracks-as-wide-as-possible-or-just-as-wide-as-needed#:~:text=if%20one%20can%20avoid%20the%20smallest%20width,a%20bit%20less%20energy%20loss%20(always%20nice) https://resources.system-analysis.cadence.com/blog/msa2021-routing-high-frequency-pcb-traces-for-signal-integrity
  
• I clicked on the first result after the AI response and found this forum which completely agrees with my capacitance concern. However, this forum is for high speed lines in general. I'll look up what I should do for USB.
  
• I Googled "what width should you use for high speed usb signals" and found this forum for USB stuff. It says that for USB full speed (what we're using), the width doesn't really matter, but for high speed, you should just set the differential pair impedance in KiCad to 90 ohms and you will be fine.
  

=============== Week 9: =================

Entry 6: -----------------------------------------------------------------

Date: March 14th
Start Time: 09:41pm
Duration: 0.25 hours

• Moving previous journal entry to website

Entry 5: -----------------------------------------------------------------

Date: March 14th
Start Time: 01:51pm
Duration: 3.25 hours

• I’m in lab now, and I have to move quick. I have 3 hours to:
  1. Remove 220R resistors from keypad
  2. Put keypad TVS diodes before resistor
  3. Ask about thicker power lines and Ahbijay’s concern that you can’t connect thicker power lines to the microcontroller
• To do #1, I have to go into the schematic first and remove the 220 resistors.
• I see some weird routing in the PCB that can be optimized. I’ll do that at the end if I have time.
  
• I asked Abhijay and Brandon in discord how to get rid of the ground plane and route stuff on the back (I don’t have to do this yet, but I will have to soon).
• Abhijay told me to ctrl + X the ground plane to remove it, ctrl + v to put it back, and then run DRC to get rid of the bad parts of the ground plane.
• I rerouted this signal better because I couldn’t help myself. Now I have to figure out how to put the ground plane back.
  
• I selected the zone and then pressed b, and it filled it back for me.
  
• I need to remove these 220R resistors and make the net names all the same.
  
• Actually, I think it will be easier to change all the 220R resistors to 1k resistors and get rid of the 1k resistors by the keypad.
  
• Done. Now time to route the PCB.
  
• I’m just going to delete the ground plane and then re-add a filled zone when I’m done. I think that’s easier for me.
• I will first arrange the TVS diodes so then they are close to the keypad connector. Then I will arrange the resistors, and then I’ll route.
• I arranged everything. (red stuff are resistors, and blue stuff are TVS diodes). Now time to route. I will route the top layer first and then put vias where convenient and route the TVS diodes after.
  
• Finished routing for keypad. Now time to run DRC.
  
• I ran DRC and it gave me a bunch of silkscreen warnings and two things I need to look at.
  
• I don’t know what the error means, so I’ll look it up.
• I think based on this forum “spokes” means the number of connections to the ground plane. There are clearly two connections to the ground plane, but if you highlight only the area I redrew, the area I redrew only covers one of the spokes. I’ll redraw the area so it covers both spokes now.
  
• Redrew the area by right-clicking and pressing create corner. Running DRC now doesn’t give any errors, but the footprint warning is still there.
  
• Got rid of the footprint warning by right-clicking on the footprint, and then pressing update footprint. I’ll get rid of the silkscreen warnings now.
• Got rid of all DRC warnings, except for the USB silkscreen getting clipped by the board edge. That’s fine since the USB will hang off the board.
• I looked at the 5V, 3.3V, and GND traces and I think I can make them thicker. I will try to do that now.
• They are 0.25mm thick, and I will change them to 0.5mm thick by clicking on the trace, pressing e, and then changing the thickness. Resistance is proportional to 1/A, so this will reduce the resistance of the traces by 2.
• I found out you can change default trace widths clicking the Track dropdown menu in the top left corner, clicking edit predefined sizes, and then adding 0.25mm and 0.5mm.
• There are some pins in the middle of the microcontroller that I cannot make thicker. I will just leave those as is. Since most of the line is thick, most of the resistance is going to be low, so I think it’s fine.
• Made all the 5V and 3.3V traces thicker. Now time to find all the ground traces and make them thicker too.
• Made all the ground traces thicker. Now time to run DRC and fix all the errors.
• Fixed all the errors. You can see the thick traces around the board now.
  
• Time to export the files and submit for review.
• Abhijay told me to move the silkscreen, so I’ll do that now.
• Moved silkscreen, so the components don’t cover it.
  
• I’m zipping the KiCad folder and uploading to the website. Then, I have to email Shivam telling him that I completed the PCB.
• Emailed our mentor TA, Xiang, Shivam, and Phil Walter. Shivam is in lab right now, so I will wait for him to be free and ask him for approval.
• Emailed the rest of the course staff because apparently I had to do that.

Entry 5: -----------------------------------------------------------------

Date: March 14th
Start Time: 12:35am
Duration: 0.25 hours

• Moving previous journal entry to website and adding pictures.

Entry 4: -----------------------------------------------------------------

Date: March 12th
Start Time: 12:30pm
Duration: 2.00 hours

• Went to Phil Walter’s meeting. We need to:
  • Show PCB changes that Abhijay did last night (I think he pulled an all-nighter, rip)
  • See what Abhijay did and implement the rest of Shivam’s suggestions.
    
  • Verify PCB layout
  • Update schematic, PCB, and Gerber file on the website
• Abhijay did 1, 4, 5, 6, and 7. Brandon did 9. I think the main thing that we need to do is #2.
• Phil Walter came up to our team. His suggestions:
  1. Fix acute angles by bottom right side of microcontroller
  2. Remove flash IC SPI debug header because we can just put an oscilloscope probe right on the chip pad
  3. Make 3.3V LDO pad bigger for thermal dissipation
  4. Add big ground via to clip oscilloscope to
  5. Add ESD protection to the keypad and fingerprint (and maybe LCD)
  6. Put moating around crystal
  7. Make power lines thicker
• See what we need to get for footprint verification
  • We have literally nothing for footprint verification.
  • Top priority for verification: MCU, flash IC, reset button, ESD protection chip, LDO, USB-A female connector
  • Low priority for verification: debug headers, programming headers, JST connectors
• Fixed acute angles and weird routing (#1 on the checklist) by rerouting stuff.
  
• Noticed that power is connected in the programming header. That means that we can only program the board when it is not connected to the computer. That should be fine, it’s just something to keep in mind.
• Did #2 on the checklist by updating the schematic, pressing tools -> Update PCB from Schematic, and then deleting the routing on the PCB.
• I need to look up how to make a pad on the PCB for #3 on the checklist.
• Found this tutorial which told me how to do it. You press add filled zone, select the VBAT net, click around and make a polygon, and then press b to fill in the zone.
  
• I need to look up how to make a via bigger for #4 on the checklist.
• This forum says that you shouldn’t use vias for anything besides connecting signals. Let me look up, “how to make a hole which you can clip an oscilloscope probe to PCB”
• Actually, since Phil Walter explicitly told us via, I think it’s okay to make it a via. I found out how to change a via diameter by right-clicking on the via, going to properties, and changing the via diameter to 6mm.
  
• I’ll tell everyone that I did suggestions 1-4 on the checklist. We need to finish that checklist by the end of the week.

Entry 3: -----------------------------------------------------------------

Date: March 10th
Start Time: 01:25am
Duration: 0.50 hours

• Time to move the remaining journal entries to the website and add pictures.
• My week 8 journal entries 9 and 10 were originally one entry in my Google doc because I counted the presentation time. I don’t know if that counts (and I really don’t need the hours), so I split up the entries and didn’t count the presentation hours.
• 55 pictures and 1 video moved total between this entry and last entry. 7,840 words read and proofread. I’m so glad to be done. Good luck to the grader.

Entry 2: -----------------------------------------------------------------

Date: March 9th
Start Time: 03:47pm
Duration: 4.00 hours

• Moving all entries from March 3rd to March 8th to website and adding pictures.
• I have so many photos in all different places (my phone, discord, my downloads folder on my computer, and my screenshots folder on my computer), so this is going to take a while.
• Good luck to the TA. Everyone is going to have monster journals for week 8, including me. I underestimated how long reading through all my journals and inserting pictures and doing all the formatting was going to take.
• I am going through the flow of copying and pasting my journals from google docs, reading each bullet point, making slight clarity changes if necessary, transferring the image to the website when necessary, and then going back and changing all the image widths so they’re visible but not too big. How have I been working this long. I wonder how many pictures I will have in the week8 folder by the time I’m done. I’m at 44 right now.
• I need a break. I’m going to get dinner and then continue moving journals. Moving 16 hours of entries to the website in one sitting is crazy.

Entry 1: -----------------------------------------------------------------

Date: March 8th
Start Time: 02:20pm
Duration: 0.50 hours

• I’m thinking of ways to reroute SPI lines for our flash ICs so we don’t need vias. The flash IC SPI operates at 24MHz, which is pretty high speed, so we care about traces. I came up with these designs and sent them to my groupmates. 1, 2, and 3 represent MOSI, MISO, and SCK in no particular order.
  
• Abhijay sent me the actual locations of the 1, 2, and 3 signals on the microcontroller and the flash ICs. Time to brainstorm again.
  
• Came up with this via-less design.
  
• Abhijay is trolling, he sent me the wrong locations. He sent me another picture with the correct locations.
  
• Came up with this 2 via design. I don’t know if it’s possible to get rid of the 2 vias, since 3 has to go around 1 and 2 somehow.
  
• I have an idea. Maybe I can rotate the flash ICs 180 degrees and make 1 and 2 go around 3. It might look a little stupid, but it might be via-less.
• Nope, I can’t figure it out. It might just be impossible. Anyways, maybe we can use some of these ideas to reroute our flash IC SPI and get rid of some vias. I don't care about vias for all the other signals.

=============== Week 8: =================

Entry 10: -----------------------------------------------------------------

Date: March 7th
Start Time: 05:20pm
Duration: 0.25 hours

• During the presentation, I got a question about current consumption differences between the UART Fingerprint Sensor A and UART Fingerprint Sensor D. I will look at that now.
• I found that both the A current consumption and the D current consumption are both listed as under 50 mA. https://www.waveshare.com/uart-fingerprint-sensor-d.htm https://www.waveshare.com/UART-Fingerprint-Reader.htm So, current consumption is probably going to be similar for each of them, and if it turns out to be a problem, it will be a problem for both.

Entry 9: -----------------------------------------------------------------

Date: March 7th
Start Time: 03:00pm
Duration: 1.25 hours

• Practicing the presentation. Stuff I’m practicing:
  • Presenting the whole story with my fingerprint sensor (looking for at least 4 fingerprint capacity, flat, and cost, basing it on these criteria, what we chose and why)
  • Presenting the block diagram (explain how everything connects together)
  • Telling Joshua how to present the PSDRs (explain why we need each PSDR)
  • Presenting my prototyping videos (I learned I need to make them fullscreen)
  • The project overview
• I'm also trying to practice being enthusiastic. Bringing energy to a presentation can make it so much more interesting.
• Put who was presenting each slide in the speaker notes.

I know there is like no detail here for 1.25 hours of work but what else am I supposed to put? I just practiced speaking and did a bunch of runthroughs. I practiced until a lot my awkward pauses while presenting were gone. I also practiced listening to my groupmates and looking at them while they were speaking.

Entry 8: -----------------------------------------------------------------

Date: March 6th
Start Time: 07:32pm
Duration: 2.75 hours

• Here is a software progress diagram I made for the presentation:
  
• Remade the block diagram because the one we had was kind of troll.
  
• Walking to armory to get my diabolo (juggling prop) lights for reference for Joshua (the guy working on the casing) to physically inspect.
• Working on cleaning up the website. I need to:
  1. Update the about me
  2. Update the datasheets
  3. Add the PCB and Schematic files
• Finished step 1
• Finished step 2
• Abhijay is the one that needs to do step 3. I’ll do that when he comes back. For now, I’ll watch Joshua make the case and see if I can learn anything / contribute.
• I need to measure the dimensions of the components we have for Joshua. Actually, let me find datasheets for them.
• The dimensions for the keypad and the LCD were in the datasheets on the website. The fingerprint sensor required me to go to the wiki and download the drawings.
  
• Brandon just finished step 3 in the checklist. Time to fully focus on Joshua stuff.
• Brandon wants me to edit the documents on the website. I’ll change the Bill of Materials, and then I’ll go back to Joshua stuff.
• Changed fingerprint sensor, flash IC, and LCD display parts in the Bill of Materials. Now time to spectate Joshua, I don’t really have too much else to do.

Entry 7: -----------------------------------------------------------------

Date: March 6th
Start Time: 01:58pm
Duration: 3.00 hours

• I did some thinking about my fingerprint sensor choice, and I realized that the Waveshare Fingerprint Sensor D has almost the exact same pinout as the Waveshare Fingerprint Sensor A. The only difference is that RX and TX are swapped. If it had the same pinout, we could just order the PCB and prototype with the fingerprint sensor, and if the D fingerprint sensor worked then we could just connect that onto the PCB instead of the A fingerprint sensor. But that is not the case.
• Instead, what I thought about was to email Shivam and ask him if the Waveshare Fingerprint Sensor D (or C) was in stock. If it was in stock, then we could just prototype with it today, since all my code for the A fingerprint sensor should work with the other fingerprint sensors too. If it isn’t in stock, then I would tell him to not worry about it, and we would just use the Waveshare Fingerprint Sensor A in our final design.
• There are two main reasons I prefer the D fingerprint sensor over the A fingerprint sensor, the shape and the cost. The shape makes it much easier for the user to input their fingerprint, since it’s easier to input your fingerprint flat onto a rectangle rather than sideways. It’s also less complicated to mount since we only have to mount one thing rather than two. The second is the cost. The A fingerprint sensor costs $43, but the D fingerprint sensor costs $17.
  
• WAIT, I JUST REALIZED SOMETHING MASSIVE. I DON’T HAVE TO CRIMP THE WIRES IN ORDER! When we connect the fingerprint sensor to the board, we have to crimp the wires into a connector. I don’t have to crimp the wires in order! I can attach pin 3 (connected to UART TX of the microcontroller) to pin 4 in the connector, and attach pin 4 (connected to UART RX of the microcontroller) to pin 3 in the connector! That way, the D fingerprint sensor can still work with our PCB!
• Ok, I filled out the component checkout form for the Waveshare Fingerprint Sensor D.
• I looked up the pros and cons between optical and capacitive fingerprint sensors. Capacitive fingerprint sensors are harder to spoof because you can’t just present it with a 2D image of a fingerprint. However, they get more messed up by dirt / water on your finger.
• Ok now I have to work on the slides.
• Double-checked the PCB. I told Brandon and Ahbijay to make the 5V and 3.3V lines thicker, and to remove the acute angle on the bottom left of the board by C2.
  
• Created the first slide and the Team Members slide by downloading the individual images from the website.
• Creating the project overview slides. I have to somehow condense the functional description into something that I can put on the slides. And also somehow add in a bit of the initial project proposal of why you would buy our product.
• Maybe I can start by introducing the major components, and then go on to explain how the major components work in our design.
• Nevermind, I think it’s better if I introduce the functionality and the major components simultaneously. Something like, “there are two methods of authentication - the keypad for entering a PIN, and the fingerprint sensor.”
• I’ll create a separate slide for the initial project proposal part.
• Why is our USB Drive better than the ones on the market right now? I could say that the fingerprint sensor makes entering your password more convenient. What else can I say?
• Let me just brainstorm all the pros and cons here (compared to this https://apricorn.com/aegis-secure-key-3nx which is the most similar product to ours):
  • Pros: Fingerprint sensor makes entering password more convenient. Multiple users makes it so then you don’t have to buy 4 different USB drives.
  • Cons: Probably higher cost. Bigger, so less portable.
• Google Slides said “unable to save changes” so I created a duplicate on my drive. But then, after I created a duplicate, the problem resolved itself. I guess we’re fine now.
• Why is having more than 1 user a pro? Maybe I can justify that by saying that our main consumer are probably corporations, and they have more than one employee that needs to access secure data. So, if the employees don’t have to use the drive at the same time, they could save cost by buying one USB drive rather than 4. I think that is convincing enough for senior design purposes.
• I am rehearsing out loud a lot so then I know how I’m going to present my slides. What I rehearse out loud is what I’m going to put in the presenter notes.
• Creating the prototyping demo slides. I saw a group put videos in their presentation and I thought it was pretty cool, so I'll do the same thing.
• I’m uploading all the demo videos to YouTube so I can attach them in the slides.
• Nevermind, the YouTube UI makes the videos look terrible when you put them in the slides. I’ll upload them to google drive instead.

Entry 6: -----------------------------------------------------------------

Date: March 5th
Start Time: 09:40pm
Duration: 0.50 hours

• Creating the major components slide for my fingerprint sensor
• I just realized, how am I supposed to present my justification for using a $43 fingerprint sensor, when there is a $17 fingerprint sensor manufactured by Waveshare that meets all our requirements? Do I have to present the whole story of my GROW R502-A fingerprint sensor getting rejected without me knowing for 1.5 weeks, my Adafruit fingerprint sensor burning up and me finding 3 different forums of people having the same issue as me, and then me resorting to the only fingerprint sensor that the ECE 477 lab had in stock? Do I have to do that? I mean, if I present that, I think it’s very understandable why we’re using the $43 fingerprint sensor, but it’s so unsatisfying when in a personal project without any deadline I would just buy the cheaper Waveshare fingerprint sensor and try that. I think I have to present that.
• I need to find a way to design my slide where I can compare against different fingerprint sensors. Let me see if I can find an example presentation where they do that.
• I think I’ll just create different columns comparing the fingerprint sensors. Namely, price, fingerprint capacity, image dimensions, and sensor type (capacitive, optical, ultrasonic).
• Finished that slide. I need to research the difference between capacitive and optical fingerprint sensors now, so I’m ready to present that.
  

Entry 5: -----------------------------------------------------------------

Date: March 5th
Start Time: 03:10pm
Duration: 3.25 hours

• Time to test my new Waveshare fingerprint sensor code. I’m going through hell with this thing, bro.
• Time to wire up the fingerprint sensor.
• Wired up the fingerprint sensor by connecting pin 1 to 3.3V, pin 2 to gnd, pin 3 to microcontroller RX, pin 4 to microcontroller TX, pin 5 to 3.3V, and pin 6 NC.
  
• Hooked up the oscilloscope to UART RX and UART TX. Now time to run my code to test my delete_specified_user function with user_id set to 1, since that’s the simplest command I wrote.
• Oh wait, I have to change my UART settings since this is a different fingerprint sensor. These are the UART settings according to the datasheet:
  
• Changed the UART settings in the IOC file and on the oscilloscope. Time to test again.
  
• The TX looks good except for the checksum (2nd to last byte), which should be 0x05 (0x04^0x00^0x01^0x00^0x00 = 0x05). I’ll go check that in the code.
  
• I changed the calculate_checksum function to actually be correct. We need to XOR the 2nd through 6th bytes, which means index 1-5. I accidentally XORed indexes 2-6. Time to test the code again.
  
• Ok, the TX looks good now on the oscilloscope (checksum is correct). Now time to see if the fingerprint sends anything back to RX by changing the oscilloscope trigger source to probe #2 (the probe connected to RX).
  
• The fingerprint sensor is returning something! It returns 0x05 (5th byte), which corresponds to ACK_NOUSER, which makes sense since we are trying to delete a user that doesn’t exist.
  
• I put the acknowledge #defines from the datasheet in my header file since I think these will be helpful to have later for easy reference.
  
• Time to see if my code is reading the data correctly. I will use the debugger to see the value of ack_type. According to the oscilloscope, ack_type should be set to 0x05 after the function call.
  
• IT WORKS, YAYYYYYY!
  
• Now time to see if I can save a fingerprint, and then see if I can compare a fingerprint.
• I need a way to see that my fingerprint registered. I’ll use the oscilloscope for that right now, which is a little scuffed, but I think I can do it. I also need to register my finger before the fingerprint sensor timeout ends, so I’m going to have to be quick.
• Actually, there is a command to change the fingerprint timeout. I’ll read the datasheet to see if I can make the timeout like 10 seconds or something.
• I can make the timeout 10 seconds by setting the timeout value to 50 (10s / 0.2s = 50). I will go write a command to do that.
  
• Created the set_timeout function by calling send_and_receive_command with the correct parameters. Now time to send it to the fingerprint sensor.
• I am getting an error which says “Failed to start GDB server” when I try to run my code. I’ll look this up.
• I didn’t find anything on the internet, but what did work was unplugging the USB cable from the computer and replugging it in.
• The fingerprint sensor is sending back 0x32, which corresponds to 50. So the fingerprint sensor is setting the timeout correctly. Now time to try my add_fingerprint function.
  
• Wrote the code. All my functions are blocking until the fingerprint sensor returns something, so the code shouldn't overload the fingerprint sensor with UART commands. I think this should work.
  
• Now time to test it:
  1. start a debug session with a breakpoint on the line before my three add_fingerprint function calls
  2. press resume to go to the breakpoint
  3. push single on the oscilloscope
  4. put my finger on the fingerprint sensor
  5. press step over in the debug menu
  6. read the response on the oscilloscope
  7. lift my finger
  8. repeat steps 3-7 2 more times
• I followed the above steps. I got to the third response (you can see it’s the third response because the second byte is 0x03), and the confirmation code (5th byte) is 0x01, which means ACK_FAIL. I don’t know why it failed. I’ll try it again.
  
• I think I know why. The first response returns 0x06, which corresponds to ACK_USER_EXIST, which probably means that there is already a fingerprint in user #0. I’ll first delete user #0 then.
• That worked. The backlight now turns on when the fingerprint sensor wants a fingerprint. However, my add_fingerprint function is now returning FINGERPRINT_HAL_ERROR for some reason. I’ll run it again to see if the error is consistent.
• It is consistent. I’ll step into my functions to see if I can see where the issue is.
• It is not getting triggered by my delete_specified_user function. I’ll keep debugging to see if it’s getting triggered by my add_fingerprint function.
• OH, I see. The timeout for my HAL_UART_Receive function is too short (how long the code should wait for the RX data). How should I do this? For some commands like delete_specified_user, the timeout should be pretty short, but for add_fingerprint, the timeout should be pretty long (like 20 seconds). At the same time, I don’t know if I want to hold up the microcontroller for 20 seconds. Should I switch to interrupts for RX? How would the programmer know when the RX sends then? Would I need to add a bunch of code inside the ISR?
• I think I’ll just add another parameter to my send_and_receive_command called timeout. Timeout will be 1s for most functions, but for add_fingerprint, I’ll make it 20s.
• Added this. Now time to test again.
• It works according to the debugger. The ack_type is 0, which means ACK_SUCCESS. The status is also FINGERPRINT_OK, which means that ack_type is valid.
  
• Now time to test my compare_1_1 function. I’ll turn the blue LED (LD2) if the fingerprint matches, and turn on the red LED (LD3) if the fingerprint doesn’t match. I’ll put this code inside my while loop, with my add_fingerprint stuff before my while loop.
• Wrote the code. Now time to run it and test it by trying my finger, and trying Brandon’s finger.
  
• IT WORKS! Here is a demo video showing the fingerprint sensor working:
  
• Now I need to commit my code to GitHub (fingerprint sensor branch) and create a pull request into the main branch.
• GitHub says that my merge conflicts are too complex to resolve in the web editor. I’ll look up how to do this now.
• Found https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github which tells me how to resolve a merge conflict once I create a merge commit. I can create a merge commit in GitHub desktop by checking out to the main branch, pressing the “choose branch to merge into main” button, and choosing the fingerprint sensor branch. Then, it leads me to a different menu where I can look at each file individually and resolve conflicts.
  
• Whenever I didn’t understand a merge conflict, I just accepted the incoming change. Most of these files, I’ve never touched in my life, and probably would get ignored if we had a gitignore for CubeIDE.
• We probably have to reconfigure the IOC file in the main branch, but that should be okay. I finished the merge. Brandon thinks we’re cooked.
• I noticed that there was an extra LCD branch, so I asked Brandon what he changed. There are some code quality improvements, so I’ll merge the branch and delete it.
• I resolved all the merge conflicts by accepting all the changes from the main branch. I don’t know what any of the merge conflict files are.
• We probably broke something. Anyways, time to get dinner, give the PCB guys the new pinout for the fingerprint sensor, and then come back to lab to work on the presentation.

Entry 4: -----------------------------------------------------------------

Date: March 4th
Start Time: 11:38pm
Duration: 2.00 hours

• I’m going to read the datasheet for the Waveshare fingerprint sensor to see if I can understand it.
• I read the list of commands and I think I understand enough of everything. I don’t exactly know what command 2.1 does (the datasheet says “Enable the module into a dormant state”, but what does that mean), so I’m going to look that up.
• I can’t find anything on the internet, so I’m just going to assume that puts the fingerprint sensor into some sort of sleep mode, and I’m not going to use it.
• Time to list the commands I think I need to send for the Waveshare fingerprint sensor:
  • To load a fingerprint: Delete specified user (2.4), Add fingerprint (2.2).
• I cannot figure out how to see if a fingerprint matches a different fingerprint that has been stored. It might have to do with the eigenvalue commands that I don’t understand. I will look this up.
• Apparently according to this website it should be the Verify 1:1 command. There is a Compare 1:1 command in the datasheet, but I don’t see how I would know whether the fingerprint matches or not. Maybe it returns ACK_SUCCESS when there’s a match and ACK_FAIL when it’s not a match? I’ll go with this assumption for now and test it in lab tomorrow.
  
• Ok, time to write the code for the new fingerprint sensor. I should be able to reuse a lot of my code from earlier, but I think here is the list of modifications I need to make to my existing code:
  1. Change the generate_package function to generate a package that matches the new format
  2. Change the calculate_checksum function to match the new format
  3. Change the receive_acknowledgement function to check the correct things.
• Finished steps 1 and 2. The fingerprint sensor packets being a fixed length makes coding stuff really easy. I just arrange all the data according to page 3 of the datasheet and put it into buff. Now time to change all the functions that call these functions to call them correctly.
  
• Finished doing that. Now time to move onto making receive_acknowledgement check the correct things - namely checking that the first byte, the last byte, CMD, and CHK are correct.
• Finished doing that. Here is my code for reference. It reads the UART data, generates the expected result, compares the received data to the expected result, calculates the checksum to see if it’s correct, and then writes to the out parameters q1, q2, and q3. (Do I need to write that? I explain all of that in my comments. I feel like I’m writing stuff twice, but I got points off for not explaining and writing a task list last week.)
  
• Now I need to update the send_and_receive_command function, and I’ll be done rewriting my code that all the commands will use. Then I can write my delete_specified_user, add_fingerprint, and compare_1_1 functions.
• Updated the send_and_receive_command function (literally just calls send_command and then calls receive_acknowledgement). Now time to move onto writing the specific command functions.
  
• I just realized that often, q1, q2, and q3 (the return parameters) are not all used. So, I should add the option of making them null to my receive_acknowledgement function. I added that.
  
• Wrote my delete_specified_user and compare_1_1 functions. They’re just wrappers for the send_and_receive_command function with the correct parameters passed in.
  
• What I’m not so sure about what to do is how to write the add_fingerprint command. That requires the user to press their finger 3 times, so we need to send and receive UART data 3 times. We probably want to keep track of the number of presses, so we can update the LCD screen every single time. It would say something like “press finger down 1st time”, “press finger down 2nd time”, and “press finger down 3rd time”.
• I think the easiest way for me to do this is to have 3 different functions for each of the different times you need to press your finger down. So, I will write the add_fingerprint_1, add_fingerprint_2, and add_fingerprint_3 functions.
• Actually, that’s a lot of copy and pasting, so I’m just going to create one add_fingerprint function with an extra parameter that tells the function whether it’s the first, second, or third time.
• Wrote it. I also had to add FINGERPRINT_INVALID_PARAM to my Fingerprint_Status enum because the user can input something invalid for press_num.
  
• Pushed code to GitHub. I will test this in lab tomorrow.

Entry 3: -----------------------------------------------------------------

Date: March 4th
Start Time: 04:55pm
Duration: 1.75 hours

Datasheet for the GROW fingerprint sensor can be found here: https://engineering.purdue.edu/477grp20/Files/refs/R558-S_fingerprint_module_user_manual-V1.1_1___2___1_.pdf

• Here is my mini checklist for today:
  1. Check baud rate on oscilloscope, datasheet, and cubeIDE.
  2. If all of them are correct, then strip the female to female wire and solder the fingerprint sensor wire to the female to female wire. Do this for both the RX and TX wires.
  3. Test again
• Turned on the soldering iron so that in case I need to solder, the iron will already be hot.
• I checked CubeIDE, the datasheet, and the oscilloscope, and all the baud rates match. I did find something interesting in the datasheet, namely that you can change the baud rate that the fingerprint sensor communicates at. I now have two options of trying to fix the issue: reducing the baud rate, or soldering the fingerprint sensor to the female wire. Stripping and soldering to the female wire is a permanent thing, so I think I’m going to try to reduce the baud rate first before trying that. Reducing the baud rate isn’t a big deal, since we don’t need the fingerprint sensor communication to be fast.
• I need to look in the datasheet to find out how to reduce the baud rate now.
• By ctrl + F for “baud rate” in the datasheet, I found the WriteReg command, which lets me change the baud rate by writing to register 4. I will write a program to repeatedly try to change the baud rate to 9600 bits / s by using my send_and_receive_command function. The fingerprint sensor will probably accept at least one of the commands if I repeatedly keep trying.
  
• I wrote the code. It’s very similar to the other command functions that I wrote. In my main function, I call this function with register_number = 4 and contents = 1, since that corresponds to the baud rate register and 9600*1 baud rate. Time to send this to my fingerprint sensor and see if it ever sends a confirmation code back with the oscilloscope.
  
• I misconfigured the oscilloscope, so I couldn’t get a confirmation code in time. The fingerprint sensor will only ever send one confirmation if you change the baud rate, since once the fingerprint sensor changes to a different baud rate, it can no longer read the old baud rate. I’ll just switch my cubeIDE to 9600 bps now, and see if I can send commands again.
• Nope the fingerprint sensor is not responding. I’ll put the oscilloscope pin on the TX pin and set my CubeIDE back to 57600 baud rate to see if I’m actually sending the right command.
• The data on the oscilloscope seems to be correct according to the datasheet. The 4th to last byte is the register number (which should be 4), the 3rd to last byte is the contents (which should be 1), and the last two bytes are the checksum, so 0x0019 is our checksum. 0x1+0x0+0x5+0xE+0x4+0x1 = 0x19, so that’s right.
  
• Ok, the code has been running for a bit now, so I’ll go back to 9600 baud rate and send my get_img command to see if the baud rate has changed.
• The fingerprint sensor is not responding. I’ll try sending my get_img command at 57600 baud rate to see if I can get the fingerprint sensor to respond at all.
• Nope, I can’t. Maybe I try increasing the baud rate slightly and then see if the fingerprint sensor responds, since the fingerprint sensor waveform seemed to imply that the fingerprint sensor was sending its acknowledgment too quickly (Since the stop bit was being interpreted as the MSB bit).
• I changed the baud rate to 62000 and sent my send_command function, but it didn’t work. I’ll go back to 57600 baud rate I guess? What else can I do?
• What if I changed the baud rate to 9600*2 instead of 9600? I guess I can try sending commands on that baud rate.
• I am sending my get_img command on 9600*2 baud rate and the fingerprint sensor is not responding. I guess I can try starting at 9600 baud rate and increasing by 9600 every time until the fingerprint sensor responds.
• I tested it. 9600, 19200, 57600 baud rate all don’t work.
• What the heck. I just touched the fingerprint sensor, and it is super hot. Did I short something? I hope I didn’t damage the fingerprint sensor.
• I took the fingerprint sensor out of the breadboard. It might be time to start prototyping with the other fingerprint sensor, if I can’t think of anything else to try.
• I’m reading through the other fingerprint sensor’s datasheet and it will take me a while to understand it. It is written in a similar format to the old fingerprint sensor, so I’ll create a list of commands that I would need to send.
• I really don’t want to abandon the GROW fingerprint sensor, since I already put a lot of effort into it. I looked up “adafruit fingerprint sensor heating up” on Google and came across this forum. Someone else had the same problem as me, and they just got a replacement fingerprint sensor. I don’t think I have time to get a replacement fingerprint sensor.
  
• I also came across this forum where someone else had the same issue.
  
• I also came across the same issue in this forum. Maybe the fingerprint sensor itself is just a bad product. I feel a lot more convinced that I should switch to the other fingerprint sensor now, even if I have to sink in so many more hours this week before Friday (our presentation day).
  
• My brain is cooked now, I will continue this some other time.

Entry 2: -----------------------------------------------------------------

Date: March 4th
Start Time: 12:45pm
Duration: 0.25 hours

• I couldn’t stop thinking about why my fingerprint sensor was sending garbage data. I tried searching up, “grow fingerprint sensor sending garbage data”, “grow fingerprint sensor sending wrong header”, etc., but I could not find anything.
• I also tried looking in the datasheet for any possible way the fingerprint sensor could be sending 0xEF81 as the header, and I found nothing. I thought maybe this might be what the fingerprint sensor sends when it stalls, but nope.
• Finally, I looked at the pictures of the waveforms I took yesterday, and tried to read the UART data manually (like look at the actual waveform with the 1 low start bit, LSB first data, and then the 2 high stop bits). When I do this, I think I see the problem. I think the timing is slightly off, so then the first stop bit (stop bits are 1) is getting read as the MSB being 1 (UART is LSB first), and 0b1000 is equal to 8. In lab, I’ll double-check the baud rate configuration, but if that’s correct, I probably have to connect the fingerprint sensor more directly to the dev board to reduce noise.
• I’m thinking of stripping my female to female wire, soldering the fingerprint sensor wire to the exposed end, and then I can clip the oscilloscope onto the exposed end. I think I only have to do this for UART RX and TX since the other pins are just constant power which shouldn’t have much noise.

Entry 1: -----------------------------------------------------------------

Date: March 3rd
Start Time: 09:31pm
Duration: 2.50 hours

• I am in lab now, and I have a lot to test, so I will make a list of what I plan to do today. Here is my checklist:
  1. Cut off the end of the yellow wire, restrip and retin the end
  2. Verify that all my TX commands work on the oscilloscope
  3. Hook up the fingerprint sensor to TX and verify that the fingerprint sensor sends something back using the oscilloscope
  4. Verify that my RX code works by using printf and reading the result
  5. Use the oscilloscope to verify that the TOUCH_OUT pin on the fingerprint sensor works like I think it does. I think it pulls the signal high when it detects a finger on the sensor.
  6. Try to send the commands needed to load a fingerprint and verify a fingerprint. For reference, here are the commands again (see February 8th entry for explanations):
     • To load a fingerprint: GetImg, GenChar, GetImg, GenChar, RegModel, Store
     • In Receiving Password state: GetImg, GenChar, GenChar, RegModel, Search
• I turned on the soldering iron, since it takes a bit of time to heat up. Brandon wants to try tinning the wire, so I’ll tell him how to do it and then let him try.
• I will now start cutting off and stripping wires. You strip wires by using a sharp scissor to cut the outer plastic, using your nail to finish cutting the plastic and peel the plastic off.
• I stripped the wire. Now, I tin the wire by twisting the wire, cleaning the soldering iron in the brass thing, adding solder to the soldering iron, putting the soldering iron under the wire, and then feeding solder into the wire.
• We tinned the wire. Now time to do the second thing on my checklist.
  
• Wired up the UART TX and oscilloscope to the breadboard. Time to run code and test TX.
• I tried running the code, but the oscilloscope is completely blank, but then a constant 3.3V signal comes on the oscilloscope after a few seconds. I’ll run the debugger to see if I can figure out what’s going on.
• I checked the debugger, and tx_buff, tx_buff_size, and tx_result all look fine. The only other thing I changed was turning off the NVIC interrupt and changing HAL_UART_Transmit to HAL_UART_Transmit_IT. I’ll try using HAL_UART_Transmit and see if that works.
  
• That didn’t work. Still the same result on the oscilloscope. I’ll try commenting out my RX code to see if that could be interfering with anything.
• That works. I see UART data on my oscilloscope now. I’ll see if I can change back to HAL_UART_Transmit_IT with my RX code commented out.
  
• It doesn’t work with HAL_UART_Transmit_IT. I’ll just stick to HAL_UART_Transmit. I don’t think it’s a big deal since the fingerprint sensor will respond after TX is done sending, so I don't have to start receiving until TX is done and thus I can make my TX code blocking.
• I will now uncomment my RX code and see if this will work. I don’t know why RX code could interfere with TX code.
• Ok, uncommenting the RX code works now? I don’t know, lol. Time to move onto step 3 on my checklist. I will now hook up the RX wires and the fingerprint sensor.
• The wires that came pre-tinned are too weak to put into the breadboard, since I had to strip them more. I need to tin them again. That would be the green, the red, and the blue wires on the fingerprint sensor.
• Finished tinning the rest of the wires. Now time to hook up the fingerprint sensor to the breadboard.
• Hooked up the fingerprint sensor to the breadboard, hooked up the oscilloscope to RX, and it is sending something on RX! Here is the oscilloscope picture:
  
• Checking the datasheet and it seems correct! It is sending 02 as the confirmation code (3rd to last byte) because I don’t have my finger on the sensor.
  
• When I put my fingerprint on the sensor, the confirmation code becomes 00, which means finger collection success! Time to move onto step 4 of my checklist.
  
• I need to re-enable the pin that does printf. I changed it to use it for my keypad, but I’m done with that now, so I can use it again. I’ll look in my journal entries to see if I can find what pin that was.
• By doing ctrl + F on my journal for “printf”, I found that it’s PB3.
• Wait I’m dumb, why do I even need this pin when I have a debugger. I’ll just read the output in the debug window.
• I need to clear all breakpoints. I’ll look up how to do that.
• Found it myself. It’s in Run -> Remove All Breakpoints. I’ll put a breakpoint right after my code that reads the RX data, wire up my RX pin, and read the recorded confirmation code on the debugger.
• The confirmation code that the microcontroller is reading is not right. I’ll create a breakpoint so I can read the raw rx_data and see if that’s right.
  
• The oscilloscope is now not reading the correct rx_data. The microcontroller also seems to match the garbage data. I guess I’ll check all the connections and keep trying.
  
• I’ll try increasing the delay between commands to 2 seconds? idk.
• Nope that didn’t fix anything. I’ll disconnect and reconnect the fingerprint sensor?
• That didn’t work. What I’m especially confused about is why is the fingerprint sensor sending 0xEF81? That should be fixed to 0xEF01 every single time no matter what.

=============== Week 7: =================

Entry 5: -----------------------------------------------------------------

Date: February 28th
Start Time: 11:27pm
Duration: 0.25 hours

• Moving journal entry to website
• The yellow wire is tinned so badly because we forgot to twist it before we tinned it. I might have to cut off the end and re-strip and re-tin it sometime, but it can go into the breadboard if you try hard enough.

Entry 4: -----------------------------------------------------------------

Date: February 26th
Start Time: 12:30pm
Duration: 2.00 hours

• My fingerprint sensor came, but the exposed part of the wires are too small. So, I need to strip the wires and make them bigger.
• Stripped the wires. Now I need to tin them so they don’t fray when putting it in the breadboard.
• While doing that, I might as well tin the wires for the USB cable too.
• Josh wants to help me tin wires, so we’re doing that together.
• Finished tinning the wires. Now I need to prototype with my fingerprint sensor.
  
• Brandon is done prototyping with his LCD display, so I can disconnect that. I can also clean up a lot of the mess on our lab bench
• Finished cleaning up. My desk space is now very empty and I put all the components we’re not using on the top part of our lab bench.
  
• I still need to prototype with my fingerprint sensor but I’m sick and I want to go back and sleep. I’ll do that another time.

Entry 3: -----------------------------------------------------------------

Date: February 25th
Start Time: 05:30pm
Duration: 3.00 hours

• I plan to finish my fingerprint sensor code today. Hopefully this doesn’t take that long.
• Finished writing the send_and_receive_command function. Now time to update all the commands to correctly use this function.
  
• Updated the get_img function. I need to update the other functions in a similar way, and then I should be done.
  
• I actually think that it would be clearer if I passed in multiple out parameters and just set those instead. That way, the user doesn’t have to worry about the size of rx_data and immediately knows what each of the out parameters mean. I’ll change to that approach.
• I changed it and I think it’s better now.
  
• I forgot to put checking the rx_result in my receive_acknowledgment function. I added that.
  
• Updated all the other functions (gen_char, search, reg_model, and store). Here is the search command code along with the datasheet as another example.
  
• Built the project to check for compiler errors. I fixed the compiler errors by making minor changes like fixing typos or including stdint.h in my header file.
• Pushed the code to GitHub. I need to test all of this code in lab. I’ll probably do that tomorrow. Hopefully I have my fingerprint sensor by then, but if not, I can just use my UART TX pin to send commands to my RX pin.
• Moving past two journals to website and uploading photos.
• Disabled UART NVIC interrupt because I don’t need it.
• Abhijay just told me that the fingerprint sensor came LET’S GOOOOOOO

Entry 2: -----------------------------------------------------------------

Date: February 24th
Start Time: 06:06pm
Duration: 4.00 hours

• I might as well write UART Rx code, since I have nothing to do, and I need hours for this week. I can test it by making one UART transmit and another UART receive the other UART’s data.
• I need to find the HAL callback function that gets triggered when UART data gets received.
• I found it in the HAL datasheet.
  
• I realized that the fingerprint sensor will always send a packet right after the microcontroller transmits, so I can probably make my code blocking, wait for the fingerprint sensor to send the packet, and avoid interrupts entirely. It will make organization of stuff easier because I can have way less global variables.
• Since the fingerprint sensor always sends something right after we transmit, I created a function called send_and_receive_command that will handle that whole interaction. That function will call my send_command function that I wrote on February 18th and then a receive_acknowledgment function.
• There are two types of errors, a HAL error or the wrong data gets received. I created an enum that I can return from my functions corresponding to this.
  
• Changed my send_command function to return my enum.
  
• I need to write the receive_acknowledgment function that will receive the data, check that it’s valid, and then return the data.
• I noticed that checking the data received is probably easier if I first generate the expected result myself, which is very similar to generating the TX data. So, I created a function called generate_package that does just that.
  
• Wrote a simple function to calculate the buffer size given the size of the package contents
  
• Changed the send_command function to use the generate_package function
  
• I realized that when generating the expected RX data, I don’t know what to expect for the package contents. So, I added an option for making data = NULL in my generate_package function.
• Wrote a separate calculate_checksum function because both my receive_acknowledgment and generate_package functions need to calculate it.
  
• Finished writing the receive_acknowledgment function. You can read through my code if you want, I think the comments are explanatory enough.
  
• I need to finish writing my send_and_receive_command function, but it’s late, so I’ll do that next time. I still also need to test the gen_char, search, reg_model, and store commands that I wrote on February 19th.

Entry 1: -----------------------------------------------------------------

Date: February 24th
Start Time: 02:19pm
Duration: 1.75 hours

• I still don’t have my fingerprint sensor, so I'm going to try to program the LCD display that Brandon gave up on. It’s lighter, so it’ll probably be better for our project if we can get it to work. I found out that the SPI for that display requires 10 bits instead of 8, so hopefully sending the first two bits will allow me to control it.
  
• Wired everything to the corresponding pins except for SDO because we probably don’t need to read data from the LCD display
  
• I found out that Brandon thought the LCD display was running on SPI1, but according to the schematic, it’s running on SPI2. I convinced him to switch to SPI2, because it’s just the right one, so now we have to rewire all the SPI pins.
• I need to configure the SPI options now in the IOC file. I will look at my code from ECE 362 and follow the options exactly (except for DMA because I don’t need that yet).
  
• Brandon is close to getting his LCD display working. I’ll stop when he can display “Welcome” on the LCD display.
• Configured the SPI options. There are some options that the IOC file doesn’t let me configure (namely NSS pulse management and setting the SPI to 10 bits), so I’ll need to manually modify the registers according to the reference manual and change those myself.
  
• Nevermind, those aren’t options you can change according to the reference manual. The SPI data can only be 8 or 16 bits, and there is no option for the NSS pulse.
  
• Brandon got “Welcome” displayed on his LCD display, so I guess I’ll leave the rest to him now. Where is my fingerprint sensor, I am considering just buying it myself with my own money if I don’t have it by Wednesday. It’s not that expensive and I'll have a tracking link.
• Moving journal to website and adding pictures
• Approved Brandon's pull request from his LCD branch

=============== Week 6: =================

Entry 6: -----------------------------------------------------------------

Date: February 19th
Start Time: 05:40pm
Duration: 0.25 hours

• I can’t stop thinking about the LCD display not working, so I looked up “lcd display not lighting up arduino” and I think I might have found the answer. Pins 3, 15, and 16 say they’re NC according to page 4 of the datasheet, but according to the Arduino forum https://forum.arduino.cc/t/lcd-2x16-not-powering-up-please-help/398363 https://forum.arduino.cc/t/can-somebody-tell-me-why-my-lcd-display-wont-turn-on/281453/7, they say that pin 3 is for contrast, and pins 15 and 16 are for the backlight. Also, they say that the LCD display should turn on without any SPI commands and just DC power.
  
• Told Brandon about my findings. I think we’re gonna meet up in lab tomorrow so we can try this then.

Entry 5: -----------------------------------------------------------------

Date: February 19th
Start Time: 12:30pm
Duration: 3.50 hours

• Went to Phil Walter’s group meeting. He talked about prototyping, getting all the stuff on the website, and midterm design reviews. We are behind on prototyping (because of the whole fingerprint sensor fiasco and flash IC issues), but we are good on getting all the stuff on the website. I will test my fingerprint sensor UART code now.
• The oscilloscope is just showing random noise when I run the code. I’ll start a debugging session to see if I can see the value of tx_buff.
  
• tx_buff seems to be correct. I’ll try moving tx_buff inside the send_command function to see if that fixes anything.
• LOL I found out that the oscilloscope was not grounded. Fixing that made the signal make sense. Now I have to figure out how to interpret this data efficiently. I’ll look up if our oscilloscope supports UART reading, but Ahbijay told me that the AD2 can do that, so I might look into that if I can’t figure it out with the oscilloscope.
  
• Ahbijay asked me which pins the fingerprint sensor was connected to. I knew what all of them were connected to, except for TOUCH_OUT. That pin is used for the fingerprint sensor interrupt signal. I looked up what GPIO pins support interrupt, and according to page 649 of the STM32H7 HAL datasheet, all GPIO pins support interrupt. So, we can just connect it to any GPIO pin.
• Uploaded the HAL datasheet to the website because I’ve used it a few times.
• Found https://youtu.be/dRIjdtNw0ZU which tells me how to use the oscilloscope to read UART. I followed it (click Serial, and select all the correct UART options) and the command I send seems to match the datasheet.
  
• Talked with Phil Walter about mounting the fingerprint sensor. I asked him about my idea of soldering the wires into some through hole pins, but he said that was a bad idea. We probably have to glue the fingerprint sensor onto the case with a hole for the connector then.
• I’ll write the code for the rest of the commands for the fingerprint sensor now.
• Wrote the gen_char, search, reg_model, and store commands. I’ll test each of them later, since I have other homework to do.
• Brandon is struggling with the LCD display. I suggested that we use the 362 microcontroller, use the 362 code, and read the signals with the oscilloscope. That should work. Good luck to him.
• I'm forking my old ECE 362 lab repository and making it public so Brandon can clone it.
• Nevermind, GitHub can't make the fork public for security reasons. I downloaded the code as a zip file and sent it directly to Brandon instead.
• We tried running my code on the old microcontroller and for some reason it doesn't work. It says that it can't find autotest.o even though the directory is correct.
• We tried going into platform.ini and removing the option that mentioned the autotest file. It says build success but the LCD display doesn't light up.

Entry 4: -----------------------------------------------------------------

Date: February 18th
Start Time: 6:01pm
Duration: 0.50 hours

• Moving journal to website and inserting pictures

Entry 3: -----------------------------------------------------------------

Date: February 18th
Start Time: 1:00pm
Duration: 3.25 hours

• I probably need to work on the code at home, so let me set up the IDE on my personal laptop.
• I need to sync my IDE after pulling from GitHub, so I’ll look up how to do that.
• I’m getting this error when I try to open my core folder. Time to look it up.
  
• I found https://stackoverflow.com/questions/1531532/the-project-description-file-project-for-my-project-is-missing which says that you can delete and reimport the project. I’ll try that.
• It worked. Time to do the generate code thing, see it fail, download CubeMX, generate code there and download packages there, and then go back to CubeIDE.
• Cool, the whole thing worked (why is it that hard). Now time to create a new branch and write UART code for the fingerprint sensor.
• I need to enable UART, but there are different modes for UART. Time to look these up.
  
• I’m just going to set it to asynchronous because that’s what they do in the tutorial.
• Set the UART settings according to page 8 of the fingerprint datasheet. (57600 baud rate, 8-bit data, and 2 stop bits)
• Enabled the UART global interrupt because I need to interrupt when I receive UART data.
• I looked it up to make sure that I can use the interrupt for this purpose, and according to https://community.st.com/t5/stm32-mcus-products/how-do-i-process-just-uart-rx-interrupt-events-while-using-hal/td-p/198707 I can. Now time to generate code and look up how to send something over UART.
• We got the keypad working, but Brandon wants to keep it on the breadboard. I think that as long as we can interface with each individual component, we can worry about integration code later when we have our PCB. We flipped a coin in order to determine what we would do, and I won, so we are now removing the keypad and freeing up wires.
• Copied and pasted the example code from section 6.1.2 of the tutorial. Time to upload the code and see if it works using an oscilloscope.
• When I upload the code, it gives me the error shown below. I’ll go download ST-LINK-SERVER then.
  
• Uploading code works, but I have an error saying undefined variable huart1.
• Oh, I forgot to change it to huart5 (the tutorial uses uart1, but I use uart5). It uploads now.
• I am getting stuff on the oscilloscope (by pressing the Single option on Run Control), but I need to change tx_buff to something I can understand. I’ll change it to just {69, 0} for now. I also changed the size parameter when I call HAL_UART_TRANSMIT.
• This is what is showing up on the oscilloscope. 69 is 0100_0101 in binary, so it looks like it’s transmitting the correct data (It’s sending LSB first). The period is also supposed to be 1/57600 = 17.36us, which is about 3 periods for every 52us, and the oscilloscope seems to show that.
  
• I don’t have my fingerprint sensor yet, but I guess I’ll start writing the code to send all the commands that I need to send (see February 8th’s and February 14th’s journal entries).
• Actually, I’m going to move all of my code from main.c to fingerprint_sensor.c first so everything is more clean.
• I found out that htim7 is actually defined as extern in stm32f4xx_it.c, so I’ll try deleting the extern htim7 in main.h and just including "stm32f4xx_hal.h" in keypad.c.
• Nevermind that didn’t work, so I’ll just revert all those changes lol.
• I looked in the fingerprint sensor datasheet, and I found that all of the commands follow a very similar format. So I created a function called send_command() that all the different instructions are going to use.
  
• I wrote the get_img() function to send the GetImg command. I’ll test this function in lab tomorrow.

Entry 2: -----------------------------------------------------------------

Date: February 15th
Start Time: 11:10pm
Duration: 1.00 hours

• Moving journal to website and adding photos.
• Did the teammate evaluation survey
• I realized how much I get distracted thinking about the most crazy things while doing these technical documents lmao. I thought the Bill of Materials would be an easy copy and paste of the schematic, but it turned into me thinking about how every single component was going to work both mechanically and electrically.

Entry 1: -----------------------------------------------------------------

Date: February 15th
Start Time: 3:00pm
Duration: 5.50 hours

• Ahbijay is working on the mechanical overview. He asked us how the PCB should be mounted, and I remembered a personal project I worked with a PCB that was mounted on something that was spinning quickly. That securing method would probably work for our project.
• I sent Ahbijay a video on how that PCB was mounted and I suggested that we copy this. We would have some holes in the PCB for the 3D printed plastic to go through and some holes in the PCB for screws to go through.
  
• Discussed with Ahbijay about the USB connector. Originally I suggested that we solder a USB A male connector to our board since I already have a USB A male to USB A female cable. However, Ahbijay suggested that we should solder a USB A female connector to our board, so then the user cannot plug the board directly into the computer without an extension cable and break it. I agree with this.
• Started working on the Bill of Materials.
• I sent a collaborative link for the Bill of Materials on Discord.
• I don’t know what to fill out for each of the columns, so I’m going to go read examples to see what they want.
• I read the examples and it seems very easy. We already have a schematic, and we know the specific parts we want, so it’s just a matter of putting all the part numbers into one document.
• While looking up 48 MHz crystals, I found out that crystals and oscillators can be two different things. https://electronics.stackexchange.com/questions/524115/how-to-use-4-pin-crystal-with-power. I’m going to look up the pros and cons of crystals vs oscillators to see which one we should use.
• I found that for standalone circuits, you should use an oscillator, but for microcontrollers, you should usually use crystals. https://www.geyer-electronic.de/wp-content/uploads/2022/11/GEYER_Crystal-or-Oscillator_how-to-apply_e_07_22_V1.0.pdf I will read the datasheet to see if our microcontroller works with a crystal or with an oscillator.
• I think page 107 of the datasheet implies that you can just use a regular crystal. I will fill out the Bill of Materials with a regular crystal then.
• I’m looking at USB-A female connectors, and I want the connector to be both easy to solder and short so we don’t have to worry about the connector not going all the way in through our 3D printed case.
• I found https://www.digikey.com/en/products/detail/cnc-tech/1002-016-01101/3064752, but that’s too long and has a mix of surface-mount and through hole pins, which would probably be harder to solder.
  
• I also found https://www.digikey.com/en/products/detail/te-connectivity-amp-connectors/6364372-2/2286712 which has all through hole pins and is much shorter, so I’ll go with this one.
  
• While looking at the membrane keypad that my teammates chose, I noticed that it looked really unfriendly to try to place it on our PCB. I asked them to reconsider just using the regular keypad that we have in lab. We can just solder that onto our PCB using the header pins or use a vertical female connector.
  
• I talked with my teammates, and they said that they chose the membrane keypad because it was more weather resistant, but it was up to me to make a decision. I decided to go with the regular keypad, since I think ease of PCB placement is more important than weather resistance.
• I need to go find a different keypad then. I’ll go look up keypads on DigiKey.
• I looked in the fingerprint sensor datasheet for the connector. The connector on the fingerprint sensor is the JST SH 6 pin male connector.
  
• I tried looking online for a female SH 6 pin connector that I could just solder onto the PCB, but that just doesn’t seem to exist. The closest thing I could find was the housing for a female connector, but you have to put your own wires inside of it.
  
• The fingerprint sensor comes with a wire that you can strip and solder onto the PCB like through hole pins. I’m thinking we should just do that.
  
• I have to find an LCD display because we don’t have a specific part number yet. We are looking for an LCD display that follows the 1602-A SPI protocol.
• I cannot find an SPI LCD display lol. I can find a million different LCD displays that support the HD44780 protocol, but none like the one we used in ECE 362.
• I found a website that lists the SEH1602A LCD displays that we use in ECE 362. Now I need to find a vendor that sells them.
• Ok, I tried reverse image searching the product, and it got me nowhere. I tried Googling a lot of different prompts in quotes, and it got me nowhere. I searched on YouTube “how to use SPI with character LCD display” and it got me nowhere. Finally, I searched up “SPI character display” on YouTube and I came across a video tutorial on how to find SPI / I2C LCD displays on DigiKey????? How is it this hard?
• Holy cow, the tutorial worked. I found a 16x2 LCD display that supports SPI. I found it by going into the “LCD, OLED Character and Numeric” section on DigiKey, scrolling to “interface” in the filters section, typing in SPI, and selecting all the interfaces that had SPI in them. This LCD display is $23 though, so I’ll go try to find another one that’s cheaper.
• I found a cheaper SPI LCD display. I checked the datasheet of the LCD display and the instructions seem to match the datasheet of the LCD display we used in ECE 362.
  
• I don’t know how much a PCB costs, so I’ll use a PCB from an old project, expand it to the dimensions of a phone (since that’s our target size), and upload the gerber file to JLCPCB to get a quote.
• The quote JLCPCB gave me was $8.20, so I’ll just assume the quote for our real PCB will be about $10.
  
• I need to get a cost estimate for our 3D printed case. I don’t know how much 3D printing costs, so I’ll look that up.
• I found that the 3D printing club charges $0.15 per gram. https://guides.lib.purdue.edu/3dprinting/otherprinters I don’t know how much our enclosure is going to weigh, so I’ll look up how much a 3D printed phone case weighs.
• I found a phone case that weighs 24 grams. I’ll double that and say our enclosure is going to weigh about 48 grams, and 48 * $0.15 = $7.20. I’ll round that to about $7.
• Submitted assignment to Brightspace.
• Nevermind I found that WALC allows you to 3D print for free as long as your print job is less than 50 grams. https://guides.lib.purdue.edu/3dprinting/FAQ#s-lg-box-wrapper-22580577. I don’t know if I should change the 3D printing cost to $0 but whatever I already submitted it. It’s a good thing to keep in mind for the future, though.

=============== Week 5: =================

Entry 6: -----------------------------------------------------------------

Date: February 14th
Start Time: 3:45pm
Duration: 1.25 hours

• Sent Shivam an email inquiring about our fingerprint sensor. I wanted to check on the status of it since I had checked it out over a week ago and heard nothing.
• Shivam came up to talk to me. Apparently, our component checkout got rejected because all the vendors that sell that sensor are banned.
• We walked over to the procurement office to get me a credit card to buy the fingerprint sensor myself, but the office was closed.
• Shivam told me to email him with different links to different vendors that could potentially sell that fingerprint sensor. He also told me to email him with a different fingerprint sensor that might also work. So, I have to research other flat fingerprint sensors. I will start on the Waveshare website because that is the company that manufactured the fingerprint sensor that ECE 477 has.
• I found a fingerprint sensor that looks like it can be plugged in flat into our board. I will look at the datasheet and see if I can understand it.
  
• I’m so confused reading the datasheet. There are so many commands that have no description. I don’t know what the memory layout looks like, either. Understanding this fingerprint sensor seems like it will take many more hours. I will see if I can find GROW fingerprint sensors (the ones that I had originally researched) sold anywhere else. I think I remember seeing GROW fingerprint sensors disguised as Adafruit fingerprint sensors, so let me go look into that.
• I found the fingerprint sensor I remembered (GROW R558-S disguised as Adafruit fingerprint sensor). Let me see if the commands match what I wrote in my journal on Saturday, February 8th.
• I think the commands match pretty closely. The only difference I see is GetFingerprint and GetFingerprintEx are now called GetImg. I think I’ll just fill out the component checkout form for this fingerprint sensor, since the procurement office can buy from Adafruit.
• I filled out the component checkout form and sent a follow-up email to Shivam telling him I filled out the form. I need to update the datasheet on the website now.
• Updated the datasheet on the website. Now time to move my journal from Google Docs to the website.

Entry 5: -----------------------------------------------------------------

Date: February 12th
Start Time: 5:00pm
Duration: 0.50 hours

• Moving journal to website
• Asked someone with less than 8 hours of work this week to update the functional description since I already have so many hours this week
• Also told them to upload the documents to the website
• Moved keypad debouncing video from my phone to the website by doing the whole handbrake spiel

Entry 4: -----------------------------------------------------------------

Date: February 12th
Start Time: 12:30pm
Duration: 2.00 hours

• Went to Phil Walter’s meeting. He talked about functional description stuff, prototyping stuff, schematic and PCB stuff. We’re behind on prototyping but on time for everything else.
• Helping Brandon set up STM32Cube. I told him to download CubeIDE, try to generate code, then download CubeMX, install packages, and then try to generate code again on CubeIDE. It doesn’t work.
• I tried looking this issue up and came across this https://community.st.com/t5/stm32cubeide-mcus/changes-in-ioc-file-not-updating-the-code/td-p/661312/page/2. Not helpful. Brandon is seeing if updating his STMCubeMX is going to resolve the issue.
• In order to work on code in parallel, we have to create different branches for the different peripherals, and create a new file for each of the peripherals. I moved the keypad code to a new file, and now I will create a new branch.
• Brandon finished downloading the new version of STMCubeMX. For some reason it is still on the old version, so he is uninstalling STMCubeMX first and then reinstalling it.
• Double clicking the STMCubeMX installer did not work, so we are uninstalling all of the unnecessary STMCube programs and seeing if that lets us install.
• Back to working on keypad code while we wait
• Brandon is restarting his computer because it still doesn’t work. lol
• Restarting the computer worked????? ok
• Brandon is creating an ST account now to download packages LOL
• Team manager meeting, they told us to add stretch PSDR to functional description, add that the USB type is type A, and add the specific type of voltage regulator (LDO) to functional description.
• Brandon’s CubeIDE works now so I can focus on my own stuff.
• Finished keypad debouncing code by creating a 2d array called keypad_matrix that increments the corresponding button value when the button is pressed (at a rate of once every 4 ms) and resets it to 0 when the button is released.
• Wrote example code to test the debouncing code. After testing and seeing that it works, I put the example code inside keypad.h, so other people can see how to use my code.
• Here is a video showing me testing with 1 second debouncing:
  
• Merged keypad code into the main branch because I am done with it. Next time I am in lab, I need to start working on fingerprint sensor code.

Entry 3: -----------------------------------------------------------------

Date: February 9th
Start Time: 10:15pm
Duration: 3.00 hours

• Started moving journals from Google Docs to website and uploading images.
• There are a lot of temporary files that don’t need to be pushed to GitHub, so I’ll create a gitignore for them by copying this https://github.com/github/gitignore/blob/main/KiCad.gitignore.
• I need to add the GitHub link to the website. I’ll do that now.
• I need to add that we are going to use a USB cable to connect to our flash drive. I’ll add that to our functional description now. I’ll also add the stretch PSDR about software encryption, and add that each user gets their own designated flash chip to the functional description.
• While I’m at it, I’ll also add the LCD display datasheet to the website.
• I double-checked the LCD display datasheet because I was curious, and I found out that the frequency that I put down in the Electrical Overview for the LCD display SPI is too fast according to the datasheet. Files/refs/SOC1602A.pdf The minimum period is 300ns, which corresponds to 3.33MHz. We’ll just use 3MHz for LCD SPI then, probably.
  
• Found out the team GitHub is private, so I asked Ahbijay to make it public so I can link to it on the website.
• Ok, tangent over, time to start working on moving journals again.
• Lol these journals are so long, good luck to the TA reading these.
• Added the dev board datasheet to the references page, since we will probably need that a lot.
• Put the USB A to wires cable in my bag, so I don’t forget it.
  
• Downloaded CubeIDE on my personal laptop so I could get a screenshot of the clock configuration, which I forgot to do in lab.
  
• I need to put a video in my journal, but the video format is MOV. I tried putting the MOV on the website, but it doesn’t work. I probably need to install handbrake to make it an mp4.
• I don’t know what settings to use, so I looked up “what handbrake settings should I use” on Google. I came across this https://www.reddit.com/r/handbrake/comments/1bq42vz/what_are_the_best_settings/, and I ended up selecting the HQ 2160p60 4K HVEC Surround setting. I don’t really know what I’m doing lol.
  

Entry 2: -----------------------------------------------------------------

Date: February 9th
Start Time: 2:15pm
Duration: 5.75 hours

• I am in lab now. I brought my ECE 362 lab kit, which I think has a cable that I can use to program the dev board. I checked our lab bench and we don’t have a USB A to USB Micro-B cable yet (even though I checked it out on Wednesday, idk how long the wait times are)
• Nevermind the ECE 362 cable doesn’t fit. Let me search up a tutorial on how to use this dev board because I want to see if I can use the ST-Link programmer to program the dev board.
• I found a video that confirmed that the usb connector I was looking at is in the programming part of the board. https://youtube.com/shorts/LWoxFclaius?si=JYpPrfyNCTgflUEJ. So I was looking at the correct USB connector, which is good. So I’m more confident that whenever this cable arrives we can program the board through usb. For now, I need to go look up how to program this thing with the ST-Link.
• I tried looking in the manual for the dev board and I couldn’t find any instructions to program the board with an external programmer. I’m looking at Target to potentially buy a USB micro b cable myself. I can buy one but it’s $6.
• I might have found out how to program the devboard. Page 18 of the manual says the jumper connections that need to be on and page 19 gives the pinout of the programmer headers. These programmer headers look like they’re supposed to be used for output instead of input but I’ll give it a shot nonetheless and hook up my ST-Link using jumper wires.
  
• I connected everything besides SWO because that doesn’t correspond to anything on the ST-Link. Time to try programming lol.
  
• I need to regenerate the code because last time I was working on Ahbijay’s account. However, when I press generate code, it doesn’t do anything. Time to look this up.
• I looked it up and came across a post where someone had something similar happen to them. They said to download STM32CubeMX, so I’ll go do that.
• I pressed generate code in STM32CubeMX, and they told me to download a firmware package. Maybe this firmware package will fix the IDE as well.
• That took like 10 min but it’s finally done. It says that my code is generated and asks me for an app to open an .eww file (this sounds like Wednesday). I’ll switch back to CubeIDE now and see if it works.
• Yay CubeIDE code generation works now. I guess one way to get CubeIDE to work is to download CubeMX, generate code there, quit, and then go back to CubeIDE lmao.
• Wrote blink code I described in Wednesday’s journal in the while loop. Now time to look up how to upload code.
• I pressed the debug icon like how they do in this video but it gave me an error saying cannot open linker script file, no such file or directory. Time to look this up.
• I came across this https://stackoverflow.com/questions/69431388/stm32-build-error-cannot-open-linker-script-file-despite-having-it. The documents folder that my testing project is in is inside a network drive. I will try to start a new project which is in the documents folder on this computer instead.
• I ran the project after doing this and now it says build finished (no errors) but nothing is happening on the oscilloscope.
• The IDE says that I need to upgrade the firmware for my STLink. I’ll go do that now.
• After pressing update, it says ST-Link device lost when exiting upgrade mode. Time to look that up. I am really considering going to Target to get a micro USB cable.
• Brandon is going back to his dorm to get a USB micro cable now. He says there’s about a 70% chance he has one.
• I found this https://www.reddit.com/r/arduino/comments/18mjouq/stlink_not_updating_stlink_device_lost_when/ and the top comment says that it can be caused by a fake STLink programmer. It also says to download ST-LINK UTILITY and upgrade the firmware there. What the [redacted].
• LOL I can’t even download ST-LINK Utility because it requires administrator perms to install (and I’m using the lab computer). I’m kind of banking on Brandon’s USB cable now.
• NOOOO I looked it up and the ECE Shop is closed on weekends. I can’t go there to get a USB Micro Cable.
• Another option I have is to try to use my personal laptop to install the firmware. I’ll try that while I wait for Brandon to get back.
• I installed ST-Link Utility on my personal laptop, and now I have an error saying mfc140.dll was not found. I looked that up and came across this https://community.st.com/t5/stm32-mcus-boards-and-hardware/i-downloaded-the-application-stsw-link004-stm-32-st-link-utility/td-p/180989. Apparently, I have to download Microsoft Visual C++ 32-bit.
• I downloaded the latest 32 bit Microsoft Visual C++ from https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170. I reran ST-Link Utility and now it works.
• I updated the ST-Link firmware, and it says it succeeded. Time to plug this back into the lab computer and see if it works.
• I tried to run the code again and it says that I still need a firmware upgrade. I tried not upgrading the firmware and it doesn’t work. I tried upgrading the firmware and it still gives me the ST-Link device lost error. Brandon came back with a USB cable so I’m going to try that now.
• I tried Brandon’s cable. It again asked me for a firmware update but this time it works. Thank [redacted].
• I tried running debug but I still don’t see anything on the oscilloscope. I’m going to watch the video tutorial again https://youtu.be/eumKLXNlM0U?si=Ei5yGQ-g7_kU9kuh.
• I changed my code to exactly match the video (blink LED 2) and at first it didn’t work but after switching windows it just magically starts working for some reason. What?
• Lol it works after I shut down the debugger and not while the debugger is running. Now I’m going to try and control PC9 which is hooked up to the oscilloscope instead of PB7 which is hooked up to an onboard LED.
• OMG I GOT IT TO WORK. I just needed to write HAL_GPIO_WritePin(GPIOC, GPIO_PIN_9, GPIO_PIN_SET); instead of HAL_GPIO_WritePin(GPIOC, 9, GPIO_PIN_SET);.
  
• Time to start a real CubeIDE project and add it to the team github. I’ll try to interface with some real peripherals in this project. I’ll start with the keypad.
• I cloned the github repository and created a new STM32Cube project. I just realized we need a USB A to wires cable. I think I have that back at my dorm so I will bring that next time I come to lab.
• The only peripherals we’re really ready to interface with are the keypad and the LCD display. I’ll initialize only those pins and leave all the other pins not initialized for now.
• I need to make PB3 a GPIO output pin instead of a debug pin (SWO). I looked up what SWO does and I think it only does stuff like printf, so I can make it GPIO output instead of debug. https://community.st.com/t5/stm32-mcus-products/can-you-change-swo-output-to-a-different-gpio-i-want-to-use-the/td-p/363313
• I need to use a timer for the keypad now. I found page 26 of the microcontroller datasheet which tells me how each timer differs from one another.
  
• Actually I’m just going to look at the ECE 362 manual and copy what they use lol.
• They use the TIM7 timer. I need to configure it so then it interrupts at 1kHz.
• Looked at the clock configuration and saw that the clock frequencies were 16MHz. Set ARR = 1 and PSC = 7999 since 16*10^6 / (1+1)(7999+1) = 10^3.
  
• Found a tutorial on how to use the HAL functions to do interrupt stuff. https://youtu.be/VfbW6nfG4kw?si=d0Y1PPBSAcILX_X7. I will follow this tutorial and try to get an LED to blink with a timer interrupt before I do any keypad stuff.
• I followed the tutorial, added a HAL_TIM_PeriodElapsedCallback function, and called the HAL_TIM_Base_Start_IT function. When I run the program normally, the LED just stays on, but when I run the program in debug mode and put a breakpoint in the interrupt, I can see that the interrupt does get triggered. Maybe the interrupt is getting triggered super quickly, idk.
• I set the breakpoint ignore counter to 11, and when I press resume, most of the time the breakpoint just gets triggered immediately, and sometimes the LED does blink but it blinks too quickly.
• OH I set the interrupt period to 1kHz no wonder I can’t see the LED blinking. Let me change it to 1Hz by increasing ARR and retry.
• I set ARR to 1999 and now the LED blinks at 1Hz. We have interrupts working let’s go. Time to write keypad code.
• I wrote the code for the keypad. Toggle each row high and read the columns. I also wrote some code to turn on the LED when a certain key is pressed and turn it off if that key is not pressed. Time to breadboard the keypad now (hook up the resistors).
• Finished breadboarding. Time to upload the code and see if it works.
  
• The code worked first try LOL. That never happens. I guess I’ll test some other keypad buttons now.
• I tested some other keypad buttons and they work. I’m done for today but we still need to interface with the LCD Display, fingerprint sensor (whenever that arrives), figure out how to create a dev board for the flash chips, and figure out USB.
  

Entry 1: -----------------------------------------------------------------

Date: February 8th
Start Time: 5:45pm
Duration: 6.25 hours

• Started working on Electrical Overview
• Downloaded KiCad on my new laptop because viewing our schematic while writing the overview will make writing it much easier.
• For some reason when I open the schematic it gives me a blank schematic, so I need to ask Ahbijay (the schematic creator) if he updated the schematic on the GitHub / if he knows what’s going on.
• Ahbijay doesn’t know what’s going on, so I guess I’ll just use the screenshot of the schematic he sent in Discord.
  
• I need to find the fingerprint sensor datasheet to brush up on some specific details about the commands we need to send to the fingerprint sensor. It’s kind of a pain to find this datasheet, so I might as well upload it to the website to make it easier in the future. I’ll also upload all the other datasheets we have while I’m at it.
• Looked at the LDO on the schematic and saw that the part number didn’t match the LDO I had in mind. I looked up the specific part and I couldn’t find it anywhere. I’ll tell Ahbijay to change the LDO to the one that we’re actually using.
• I tried looking up the specific flash chip on the schematic but I couldn’t find anything online. I confirmed with Ahbijay that we’re using these flash chips. I guess all the part numbers on the schematic besides the microcontroller are just wrong lmao.
• I’m trying to access the datasheet for the flash chip, but apparently it’s under Micron’s secure content, so I need to register for an account. I also need to insert a link to the datasheet on the website instead of uploading it, since the datasheet is under an NDA.
• Finished uploading the relevant project documents. Time to go back to working on the Electrical Overview.
  
• I’m reading the fingerprint sensor datasheet to figure out the exact commands we need to send. This is probably not needed for the electrical overview, but we will need to know this in the future.
• I learned that the fingerprint sensor has onboard volatile memory called the Image Buffer and CharBuffer[1:6], and onboard non-volatile memory called the Fingerprint Library. I think I know what commands we need to send. It goes like this:
  • In Change Fingerprint state:
    1. GetFingerprintEx: get the first fingerprint sensor image and load it into Image Buffer. If this command doesn’t return 0x00 (some error occured), redo this step. The difference between this command and GetFingerprint is that this command will return an error if the fingerprint quality is bad, whereas the GetFingerprint command will return success if the fingerprint quality is bad. For a template that’s going to be stored, we want the quality to be good.
    2. GenChar: put the fingerprint into CharBuffer1.
    3. Redo step 1
    4. GenChar: put the fingerprint into CharBuffer2.
    5. RegModel: generate a template using CharBuffer1 and CharBuffer2, which is stored back into CharBuffer1 and CharBuffer2.
    6. Store: store the template into the Fingerprint Library at the address corresponding to that user.
  • In Receiving Password state:
    1. GetFingerprint: get the user’s fingerprint. If this command doesn’t return 0x00 (some error occured), redo this step. This can probably be used instead of GetFingerprintEx as we will rely on the verification command to deal with the fingerprint data. If this command is too lenient, then we can try switching back to GetFingerprintEx.
    2. GenChar: put the fingerprint into CharBuffer1.
    3. GenChar: put the fingerprint into CharBuffer2.
    4. RegModel: generate a template using CharBuffer1 and CharBuffer2, which is stored back into CharBuffer1 and CharBuffer2.
    5. Search: search the Fingerprint Library for a match. The PageID of a matching fingerprint along with a score will be returned. If the score is above a threshold and the PageID matches the correct user, transition to the Unlocked state. (We can’t use the Match command because that doesn’t return the specific user the fingerprint matched with.)
• Okay, back to working on the Electrical Overview tangent over.
• I have to write the operating frequency frequency section, but the main operating frequency that I can think about is the clock frequency. I asked my group members if we should select a 48MHz crystal because it's above the 12Mbps of USB, and we used that frequency in 362 and it worked.
• Added past ECE 362 lab manuals to website references because I’m using that quite a lot while writing the Electrical Overview.
• When writing the operating voltage level section, I needed to look at whether stuff was powered by 5V or 3.3V. When looking at the USB pins, I was confused as to why the D+ and D- pins looked like they were getting powered with 3.3V (see page 79 of the microcontroller datasheet), but I came across https://community.st.com/t5/stm32-mcus-embedded-software/to-what-voltage-should-the-d-line-be-pulled-up-when-designing/td-p/183329, and apparently it’s fine to power it with 3.3V.
  
• I tried to find a datasheet for the LCD display that we were planning to use so I could figure out what input voltage we should use, but that datasheet was super not descriptive. I ended up looking up the LCD display that we used in ECE 362 and looking at the 362 lab manual. I also convinced the group to switch to using the 362 LCD display.
• Just finished the Electrical Overview. Finding current draw is tough for some components (the microcontroller). Also, I couldn’t find a maximum SPI frequency for the LCD display, so I put 12MHz, and we will pray that works (if not, then lowering the SPI frequency is not hard)
• I need to upload the Electrical Overview to the website and also add the LCD display datasheet to the website, but I’ll do that later it is midnight and I need to eat dinner.

=============== Week 4: =================

Entry 2: -----------------------------------------------------------------

Date: February 5th
Start Time: 12:30pm
Duration: 2.5 hours

• Went to Phil Walter’s team meeting. He talked about PSDRs, functional descriptions, prototyping, PCB Training. Brandon and Abhijay are working on PCB. I need to start learning CubeIDE and start learning how to use the devboard so we can do some actual prototyping.
• Logged into Abhijay’s account because he already downloaded CubeIDE
• I tried to generate the code but it says the code was generated and asks me what app to use to open an .eww file. I don’t know how to proceed so I guess I’ll look up a CubeIDE YouTube tutorial
• Talked to Phil Walter and TAs about stuff. They told us to add that each user gets their own flash chip, add the stretch PSDR about data encryption, and add that we’re putting the USB connector directly on the PCB. He also told us to consider not putting the USB directly on the PCB and instead using a cable. That might not be a bad idea because of the weight and size.
• Watched https://youtu.be/eumKLXNlM0U?si=ZXdQ83KA7GliBmW- and found out I was opening the wrong app (I was using STM32CubeMX instead of STM32CubeIDE).
• Generated the code and saw some function called HAL_GPIO_Init and control+clicked on it. I scrolled down in the file and found a HAL_GPIO_WritePin function. I want to use these functions instead of writing directly to registers if possible because it will make coding easier.
• I want to create a simple blink program to try and get CubeIDE to work.
• Read the documentation inside the file and filled out the function to set it and reset it like so: “HAL_GPIO_WritePin(GPIOC, 9, GPIO_PIN_SET);”. Now I have to find out how to delay.
• Looked up how to create a delay and found https://controllerstech.com/create-1-microsecond-delay-stm32/. It mentions a function called HAL_Delay which I will use.
• I wrote the code but now I need to actually connect the board to the computer. I need a USB cable but I need to figure out first what USB type this uses.
• Searched up STM32F413ZH usb connector and found https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.st.com/resource/en/user_manual/um2135-discovery-kit-with-stm32f413zh-mcu-stmicroelectronics.pdf&ved=2ahUKEwiy7qDMoq2LAxWqLtAFHSjXH1gQFnoECBAQAQ&usg=AOvVaw3yT8zxU7Q2L6RCB81GoAqC. I searched for programming and came across page 15 which says it’s a USB B micro connector. It also mentions a “USB ST-LINK connector” so I’ll look that up.
• Searching that up just led me to a bunch of external programmers. Not useful. I’m going to search for the term programming in the manual more.
• I searched programming and came across page 26 which says it’s a USB Micro-AB connector. idk what a Micro-AB connector is, so I’ll search it up.
• I searched it up and found nothing. I think just from physical inspection of the board it’s a Micro-B connector.
• Filled out component checkout form for a USB A to USB Micro B connector since I’m confident enough that’s the type we need.
• Hooked up oscilloscope to PC9 (blink pin) and GND. I’m waiting on the USB connector and there’s not much else I can do now without it.
• Once I get the USB connector I want to verify that the voltage is actually changing and then move on to actually interfacing with the real peripherals.

Entry 1: -----------------------------------------------------------------

Date: February 4th
Start Time: 5:30pm
Duration: 1.5 hours

• I got a new laptop, so I have to set up the website on the new laptop
• I followed all the instructions correctly on the team website setup PDF, but it didn’t work, and it gave me this error:
  
• I retried everything a couple times since the steps in the PDF had worked on my old laptop. It didn't get me anywhere.
• I looked up “windows cannot map network drive” on Google and came across an article that told me to check my firewall. I had similar problems like this when setting up a Minecraft server at home, so I decided to check the firewall.
• I went to the control panel page the microsoft page told me to go to and saw that my firewall was being controlled by Bitdefender (my antivirus)
  
• Disabled the Bitdefender firewall, and I was able to connect to the website.
• Looked up how to allow a specific network drive through Bitdefender Firewall and came across this. I followed the tutorial until it asked me to enter the IP address. I tried entering shay.ecn.purdue.edu but it didn’t work. So I have to find the actual IP address.
• I looked up how to find the IP address of a network drive and found this. I tried typing in the first answer’s commands, but they didn’t work. I tried typing in the second answer’s commands and it did work.
• I put in the IP address into Bitdefender, and now the website network drive works with the firewall on.
• Dropped off lab kit at our station so we have wires to prototype with
• Looked at the fingerprint sensor we checked out. I searched on Google the text I saw on the fingerprint sensor and found out it’s manufactured by Waveshare. However, the fingerprint sensor I was thinking of using is manufactured by GROW.
  
• I found the datasheet of the Waveshare fingerprint sensor and the UART commands are very different from the GROW ones.
• I filled out the component checkout form for the GROW R502-A fingerprint sensor, since it comes with a connector to wires that we can connect directly to the breadboard. So we can prototype with the exact part we want to use, which is great.
  

=============== Week 3: =================

Entry 3: -----------------------------------------------------------------

Date: January 29th
Start Time: 12:30pm
Duration: 3.25 hours

1. Went to Phil Walter's group meeting. He discussed refining PSDRs and functional descriptions. Our group hadn't updated ours since last week, so we had to do that.
2. Updated PSDRs with Brandon. We made them much more speciic to what we were actually going to design for the project, rather than the project's features.
3. Read example functional description. Learned that it starts off by introducing the project from the user's perspective and then goes into the specific parts. We will use that general structure when writing our functional description.
4. Added USB PSDR that we somehow forgot about.
5. Talked with Phil Walter about PSDRs, found out we should just go for our 5 hardest PSDRs and stretch PSDRs should not be essential to the functionality. The requirements that we leave out of our PSDRs will be factored into our difficulty rating instead.
6. Talked to a TA about journal entries, found out that we should include more detail about what we actually learned from everything, rather just saying what we did. Now I have to go update all my journal entries for this week lol.
7. Updated all the journal entries for this week to include what I learned and my thought process. Basicaly added a lot of technical explanations with information found from the datasheets.
8. Finished writing functional description by following the general structure described in the third list item. Also added a lot of stuff we ironed out while writing our functional specification. I tried my best to write out the state transition diagram shown below in paragraph form.
9. Refined PSDRs and functional descriptions. I tried to write the state machine diagram as PSDR, and tried to write the state machine diagram in the functional description by giving the speicifc name of each state.
10. Added the STD to the homepage because the diagram is so much more clear than trying to describe it in paragraph form. I don't know if Phil Walter will like it or not but it will give him a better understanding of whwat we want to do and thus be able to help him give us better feedback next lab.
11. Actually maybe I leave the STD for now but I just realized how much of the state transitions are included in the diagram and left out of our functional description. We need to add those into our functional description sometime in the future.

Entry 2: -----------------------------------------------------------------

Date: January 28th
Start Time: 10:05pm
Duration: 0.25 hours

• Researched more voltage regulators and found a cheaper one that still can output 1A. This is probably what we will use for our project because it can supply more than our maximum load of 500mA and can still output 3.3V when the input voltage is 4.75V (the lowest allowed by the USB 2.0 spec).

Entry 1: -----------------------------------------------------------------

Date: January 25th
Start Time: 3:30pm
Duration: 4 hours

• Met with team members to work on Functional Specification Document (I made brainstorming bullet points for computational constraints, wrote all of electronics constraints, wrote all of thermal / power constraints, and wrote all of theory of operation (including STD diagram))
• Researched the difference between different types of voltage regulators (linear, low dropout, switching). A linear regulator is the cheapest regulator but it has a higher drop voltage and dissipates all the extra power as heat. A switching regulator stores the extra power in a capacitor and thus is more efficient, however interfacing it usually requires ore external components. A low-dropout regulator is like a linear voltage regulator but has a lower drop out voltage.
• I found a low dropout regulator that is probably good for our project. It can output our 1A which is higher than our maximum output current of 500mA. and it can output 3.3V even when the input voltage is 4.75V.

=============== Week 2: =================

Entry 9: -----------------------------------------------------------------

Date: January 22th
Start Time: 6:30pm
Duration: 1 hour

• Looked at the fingerprint sensor library's source code
• Looked up FreeRTOS and found out what it is through this YouTube video (it’s a dependency of the fingerprint sensor library)
• Initially I was confused as to what all the library functions did (there’s no documentation) but I looked at the user manual for the R308 fingerprint sensor and found that the library functions just correspond to everything in the user manual.
• Found tables that compare different types of GROW fingerprint sensors (shown below). I think I want to use one of the round capacitive fingerprint sensors (the R5XX series) because it can just be plugged in flat into the PCB.
• Told group members about my findings.

Entry 8: -----------------------------------------------------------------

Date: January 22th
Start Time: 12:30pm
Duration: 2 hours

• Phil Walter’s group meeting
• researched different fingerprint sensors
• Found MIKROE-4265 which is just a fingerprint sensor dev board, not very useful
• Phil Walter met with our group individually and gave some improvements we need to implement to our functional specification and PSDRs (powered from 5V USB, describe mechanically what it looks like, add fingerprint sensor PSDR)
• Found Adafruit fingerprint sensor and the adafruit fingerprint library for Arduino.
• Found GROW fingerprint sensors (both optical and capacitive)
• Found STM32 fingerprint sensor library that supports the GROW R308 fingerprint sensor

Entry 7: -----------------------------------------------------------------

Date: January 21th
Start Time: 8:00pm
Duration: 1 hour

• Watched YouTube tutorial https://youtu.be/aEwwQMdKd-c. If we’re satisfied with about 700kB/s read / write speed then we can just use USB full-speed like the guy in the YouTube video does. Otherwise we have to use USB high-speed. He interfaces the microcontroller with an SD card instead of something we can solder onto our board, but a lot of things will probably be similar when using flash memory or whatever we use.
• Researched differences between EEPROM and flash memory and found out that USB drives usually use flash memory.
• Found flash memory that we could possibly use. https://www.digikey.com/en/products/detail/winbond-electronics/W25X40CLSNIG/3008652 Read the datasheet and learned that this uses SPI to send instructions to the flash memory (like read / write / get capacity).
• Rewinded the YouTube tutorial to the code sections where he is filling out the read, write, and get capacity functions and brainstormed how I could write code like that to work with the flash memory instead of the SD card. I think we can make it work.
• Told group members about YouTube tutorial and the flash memory I found

Entry 6: -----------------------------------------------------------------

Date: January 21th
Start Time: 5:30pm
Duration: 1.75 hours

• Finished reading Universal Serial Bus Mass Storage Class Bulk-Only Transport. I learned more in-depth about how data is transferred in and out of a thumb drive. A lot more edge cases. Nothing too much that I need to know though. I still don’t know how the host determines what address it wants to read / write to though. Maybe I have to go back and review that but once I know that then I think I know everything I need to know.
• It looks like addressing is determined by the CBWCB (section 5.1) which is an industry-standard command format determined by bInterfaceSubClass (section 4.3). And the different command formats are all specified in different manuals! This is starting to become a kind of ridiculous amount of reading and I might have to stop here. It was nice to learn about all the behind-the-scenes stuff that the USB ICs do though.
• Looking at microcontrollers with USB built in. I’m trying to skim through data sheets but I don’t know what I’m looking at.
• Found a YouTube tutorial on how to make a USB SD Card. I will watch this during dinner. https://youtu.be/aEwwQMdKd-c

Entry 5: -----------------------------------------------------------------

Date: January 20th
Start Time: 7:30pm
Duration: 0.25 hours

• Copy and pasted stuff from final project proposal to website homepage
• Uploaded final project proposal to website

Entry 4: -----------------------------------------------------------------

Date: January 19th
Start Time: 4:45pm
Duration: 1 hour

• Told group members about Ben Eater’s videos and suggested that they watch them
• Read the Universal Serial Bus Mass Storage Class Specification Overview. This basically just gives us the codes to specify that the device wants to use bulk-only transport (what flash drives usually use)
• Read up to section 5.3 of Universal Serial Bus Mass Storage Class Bulk-Only Transport. The main stuff I got from this is mainly how a flash drive should respond to SETUP commands (which is probably going to be handled by the USB chip that we’re gonna use) and an introduction as to what a data-in / data-out command looks like.

Entry 3: -----------------------------------------------------------------

Date: January 19th
Start Time: 12:30pm
Duration: 1 hour

• Watched part 2 of Ben Eater's USB series https://youtu.be/N0O5Uwc3C0o. Had to rewind a lot to understand it, but it was very helpful to see all the SETUP commands which help determine what type of device is plugged in.
• I have to look specifically into the USB thumb drive spec now (and find out what it's actually called). Ben Eater looks into the HID(human interface device) spec which is for stuff like mice and keyboards.

Entry 2: -----------------------------------------------------------------

Date: January 18th
Start Time: 6:45pm
Duration: 1.5 hours

• skimmed through final project proposal to make sure everything was finished
• found that functional description was not filled out
• came up with a list of requirements and sent it to the group discord to make sure the group members agreed upon them
• turned the list of requirements into the functional project description
• submitted to brightspace

Entry 1: -----------------------------------------------------------------

Date: January 18th
Start Time: 12:40am
Duration: 0.5 hours

Watched Ben Eater USB video https://youtu.be/wdgULBpRoXk

=============== Week 1: =================

Entry 2: -----------------------------------------------------------------

Date: January 17th
Start Time: 11:30am
Duration: 0.25 hours

Nobody on the team knows how a thumb drive uses USB to communicate with a computer. So, I've been trying to do research to figure that out. I watched Sine Lab's video on the USB protocol while eating lunch but it didn't really tell me anything I didn't learn from ECE 337. https://youtu.be/HbQ6q3skZgw

Entry 1: -----------------------------------------------------------------

Date: January 15th
Start Time: 12:30pm
Duration: 3.25 hours

• logged into website and set it up with the template files
• got assigned to hardware lead role
• learned how to navigate website using VSCode
• went on tour of lab
• explained to GTAs our project
• found out that only one person can modify website at a given time
• set up VSCode liveshare to enable multiple editors of the website at a time
• filled out home page
• read individual project journal policy
• moved journal entry to website
• filled out contact tab